To be fair, all these arguments were also raised during the 2023.2 development cycle. With additional one - we will be not able to drop support during non-SLURP release without breaking upgrades/compatibility between SLURPs. A decision was taken to keep py3.8 back then with acknowledgement of that fact.
Now, when 2023.2 has been released with py3.8 support, from my perspective there is really no way it can be removed until 2024.1 without breaking someone's upgrades.
Despite I agree with your arguments, TC has quite explicitly stated that deprecations should not take place in non-SLURP releases according to [1] deprecateion are allowed in non slurps we just cant remove supprot for a depreaction
On Wed, 2023-10-11 at 19:19 +0200, Dmitriy Rabotyagov wrote: that has not been release in slurp. ingoring that for a moment the deprecation poilcy only applies to aplciation feature we have never applied it to runtimes or minium python version.
and I believe that reasons and background in this resolution are still valid and should be respected, despite how inconvenient it might be sometimes. As also platform consumers rely on that and plan their maintenance and further work based on promises that are being made by community.
In case a key library drops support for py3.8 then I believe we will need to leverage upper-constraints to set the version back for the library to the one which supports py3.8. Either for all python versions, or solely for py3.8, like we already did for py3.6 and py3.8 back in Xena/Yoga.
[1] https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adj...
On Wed, Oct 11, 2023, 15:45 Brian Rosmaita <rosmaita.fossdev@gmail.com> wrote:
I thought about this issue some more after yesterday's TC meeting, and tried to articulate why I think keeping python 3.8 support for 2024.1 is a bad idea on the patch:
https://review.opendev.org/c/openstack/governance/+/895160
I don't know if my argument there will change anyone's mind, but since a lot of people have already voted on the gerrit review, I wanted to make sure that people are at least aware of it, to wit:
I just don't see that py38 support for 2024.1 makes sense. It's not a default version in Ubuntu 22.04, Debian 12, Debian 11, CentOS Stream 9, or Rocky Linux 9, which are the distros specifically called out in the current 2024.1 PTI that this proposal is patching.
While we can use Ubuntu 20.04 to run unit tests, we can't run master (2024.1 development) devstack in it, so it doesn't seem to me that Ubuntu 20.04 is a distribution that we can feasibly use for meaningful 2024.1 testing. This implies, in my opinion, that there is a solid reason for dropping python 3.8 support in advance of it going EOL, as required by [0].
Looking at the Python Update Process resolution [1], python 3.8 does not meet the three criteria set out in the "Unit Tests" section:
1. it's not the latest version of Python 3 available in any distro we can feasibly use for testing 2. It's not the default in any of the Linux distros identified in the 2024.1 PTI 3. It isn't used to run integration tests at the beginning of the 2024.1 (Caracal) cycle
Add to that the fact that libraries are beginning to drop support [2], add further that py38 will go EOL roughly 6 months after the 2024.1 release (no more security updates), I don't see a reason to wait until a key library forces us to make a change during the development cycle. I'd prefer to do it now.
[0]
https://governance.openstack.org/tc/reference/pti/python.html#specific-comma... [1]
https://governance.openstack.org/tc/resolutions/20181024-python-update-proce... [2] https://review.opendev.org/c/openstack/requirements/+/884564