Stop bumping major versions when dropping EOL Python versions
o/ Python 3.8 is going EOL (upstream, anyway) next month. We've been working to drop support for this from various SDK deliverables, and I'm guessing (though don't yet know for sure) that this will happen across other project deliverables before long (if it hasn't started happening already). One side-effect of this change is that we will be expected to raise the major version of the affected dependencies on our next release. This is annoying for projects like openstacksdk that use the release-with-intermediary release model because it forces us to have a major version release earlier than we would like to. To give a concrete example, we have a RemovedInSDK50Warning deprecation warning that we are using to indicate (as you might guess) things that we plan to remove in openstacksdk 5.0.0. We need to wait 6 months/1 OpenStack release before removing anything flagged with this warning, so this has been mainly applied to legacy deprecation warnings to put a concrete timeline on their removal. However, because we just dropped Python 3.8 support, it is currently expected that our next release be 5.0.0. We last deprecated something new ~2 months ago, so this means we either cannot release a new version of openstacksdk for 3-4 months (to allow 6 months to pass) or we need to either rename RemovedInSDK50Warning to RemovedInSDK60Warning or add a new RemovedInSDK60Warning and move the offending deprecations to this. None of these are nice options and to be honest, I don't think the major version bump really provides all that much value to end-users: they already have a much better signal for the removal of a Python version in the 'python_requires' marker in setup.py/setup.cfg/pyproject.toml/(other build system file). By using this, we ensure that a user simply can't install a version of a package that doesn't support their chosen Python version. I'd be in favour of getting rid of this particular constraint, and instead focusing on API changes when deciding whether to bump the major version. Is this a reasonable suggestion, and if so what would we need to do to tweak our policy to allow it? Cheers, Stephen
On 2024-09-23 12:25:09 +0100 (+0100), Stephen Finucane wrote: [...]
I'd be in favour of getting rid of this particular constraint, and instead focusing on API changes when deciding whether to bump the major version. Is this a reasonable suggestion, and if so what would we need to do to tweak our policy to allow it?
It makes sense to me. Dropping Python 2.x support was a more significant event, but these days removing support for minor Python versions after the corresponding CPython interpreter reaches EOL upstream is fairly unremarkable. We don't perform major version increments just for raising the minimum required versions of any other dependencies, after all. -- Jeremy Stanley
Hi, Dnia poniedziałek, 23 września 2024 15:22:51 CEST Jeremy Stanley pisze:
On 2024-09-23 12:25:09 +0100 (+0100), Stephen Finucane wrote: [...]
I'd be in favour of getting rid of this particular constraint, and instead focusing on API changes when deciding whether to bump the major version. Is this a reasonable suggestion, and if so what would we need to do to tweak our policy to allow it?
It makes sense to me. Dropping Python 2.x support was a more significant event, but these days removing support for minor Python versions after the corresponding CPython interpreter reaches EOL upstream is fairly unremarkable. We don't perform major version increments just for raising the minimum required versions of any other dependencies, after all. -- Jeremy Stanley
Yeah, I fully agree with this proposal and with what fungi already said. I don't think we need to bump major version every time we drop support for one of the python 3 versions. -- Slawek Kaplonski Principal Software Engineer Red Hat
Indeed, we started bumping MAJOR version due to dropping py27 support. Though, the rule is, that a change in required package's version, only warrants a MINOR version bump. But python is not just a simple dependency, and dropping support of a python version is more than just bumping any python package's version. Anyway, if the community wants to stop bumping major versions in case of dropping python version support, then i'm probably OK with that. Cheers, Előd ________________________________________ From: Jeremy Stanley Sent: Monday, September 23, 2024 15:22 To: openstack-discuss@lists.openstack.org Subject: Re: Stop bumping major versions when dropping EOL Python versions On 2024-09-23 12:25:09 +0100 (+0100), Stephen Finucane wrote: [...]
I'd be in favour of getting rid of this particular constraint, and instead focusing on API changes when deciding whether to bump the major version. Is this a reasonable suggestion, and if so what would we need to do to tweak our policy to allow it?
It makes sense to me. Dropping Python 2.x support was a more significant event, but these days removing support for minor Python versions after the corresponding CPython interpreter reaches EOL upstream is fairly unremarkable. We don't perform major version increments just for raising the minimum required versions of any other dependencies, after all. -- Jeremy Stanley
participants (4)
-
Elõd Illés
-
Jeremy Stanley
-
Stephen Finucane
-
Sławek Kapłoński