supporting only N,N-1 releases of python: too radical? #3424
Replies: 4 comments
-
Ah! I didn't want to make this PR sounds that radical. I intend to keep the code to bee conservative and still support old versions of Python. I made this change awaiting to add an external CI more supportive for legacy. It has become really hard indeed with github to hnadle CI for older projects. Let me see how I can make this happen sooner. |
Beta Was this translation helpful? Give feedback.
-
According to the Python Software Foundation (PSF), as of October 2025: Currently supported Python versions:
End of Life (no longer supported):
So for the projects and CI versions from 3.10 to 3.12 and later will be actively tested. EOL version s will be not be supported officially (you can always frop a mail). |
Beta Was this translation helpful? Give feedback.
-
#3425 is bringing back that support. |
Beta Was this translation helpful? Give feedback.
-
Great! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
It has come to my attention that Gunicorn will soon only support N, N-1 releases of Python.
It's great that some work is being done to stay inline with "what is modern". But for such a "bottom of the stack" component restricting Gunicorn to N, N-1 releases is very limiting.
Just mentioning my own personal use-case: Bugsink for using Gunicorn: something that is deployed as an application, and for which I intend to have long horizons / the ability to have slow release cycles if this is desirable from the end-user perspective. The present solution makes it so that Gunicorn becomes a bad match for such projects (and I imagine: many others).
Just as a matter of precedence/history: it also seems a rather radical departure from the past, in which an (implied) commitment to many Python versions existed, without an [known to me] reason for it
Beta Was this translation helpful? Give feedback.
All reactions