Patchman Django version policy?

[kraileth]

When evaluating software I usually try to get it packaged properly along the way so that even if I end up not using it the work is not lost and others can easily install it. Ravenports (a universal packaging framework for multiple Unix-like operating systems) has a preliminary port now. It does not work, yet, though. I ran into the following error when trying to execute patchman-manage:

TypeError: Signal.__init__() got an unexpected keyword argument 'providing_args'

A little research quickly pointed in the direction of an incompatibility between major versions of Django. I'm on version 4.2.6 while according to requirements.txt patchman currently depends on 2.2.28. I assume this is due to patch management being more of an "enterprisy" thing where distributions with longer support time are common - and those frequently ship terribly old software versions.

I'm not just playing around with patchman in my free time but hope to be able to introduce it at work, too. The problem there is: By policy we cannot use software versions that are EoL - that is non-negotiable. The Django framework's 2.2 branch has been EoL for over 1.5 years (!) now, even though it was an LTS release.

This leads to my question: What is the project's policy regarding Django versions? Are there plans to adopt 3.2-LTS (which will be EoL in less than half a year as well...) in the near future? Or to maybe skip 3.2 and go to 4.2 directly (which would receive extended support until early 2026)?

Since the client is just a shell script this obviously is just a question of which operating systems are fit to run the server, right? Debian 11 provides Django 3.2 via backports, the Red Hat world can get it from the EPEL starting with version 8. Only on openSUSE the situation looks dire outside of Tumbleweed (they also still ship Django 1.x!), and Ubuntu 20.04 also doesn't have it, but yeah. So does it make sense to hold on to a long dead version of Django with known security issues for the sake of Debian 10, RHEL 7 or Ubuntu 20.04? If so, when would be the right time to make the switch to a newer version?

This issue is definitely one without a simple right answer and probably warrants a discussion. And unless the developers know pretty well what environments patchman is usually running in this could also be something for a community poll?

[furlongm]

Please see the `develop` branch. It has django3 support and will be released shortly.

…

On Sat, Oct 28, 2023, 07:02 kraileth ***@***.***> wrote: When evaluating software I usually try to get it packaged properly along the way so that even if I end up not using it the work is not lost and others can easily install it. Ravenports (a universal packaging framework for multiple Unix-like operating systems) has a preliminary port now. It does not work, yet, though. I ran into the following error when trying to execute patchman-manage: TypeError: Signal.__init__() got an unexpected keyword argument 'providing_args' A little research quickly pointed in the direction of an incompatibility between major versions of Django. I'm on version *4.2.6* while according to requirements.txt patchman currently depends on *2.2.28*. I assume this is due to patch management being more of an "enterprisy" thing where distributions with longer support time are common - and those frequently ship terribly old software versions. I'm not just playing around with patchman in my free time but hope to be able to introduce it at work, too. The problem there is: By policy we cannot use software versions that are EoL - that is non-negotiable. The Django framework's 2.2 branch has been EoL for over 1.5 years (!) now, even though it was an LTS release. This leads to my question: What is the project's policy regarding Django versions? Are there plans to adopt 3.2-LTS (which will be EoL in less than half a year as well...) in the near future? Or to maybe skip 3.2 and go to 4.2 directly (which would receive extended support until early 2026)? Since the client is just a shell script this obviously is just a question of which operating systems are fit to run the server, right? Debian 11 provides Django 3.2 via backports, the Red Hat world can get it from the EPEL starting with version 8. Only on openSUSE the situation looks dire outside of Tumbleweed (they also still ship Django 1.x!), and Ubuntu 20.04 also doesn't have it, but yeah. So does it make sense to hold on to a *long* dead version of Django with known security issues for the sake of Debian 10, RHEL 7 or Ubuntu 20.04? If so, when would be the right time to make the switch to a newer version? This issue is definitely one without a simple right answer and probably warrants a discussion. And unless the developers know pretty well what environments patchman is usually running in this could also be something for a community poll? — Reply to this email directly, view it on GitHub <#519>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4A43PLX6IMPOIPVGCH53YBTQ4NAVCNFSM6AAAAAA6UAIMW6VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZVG44DMNRYGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>