Open Stack

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]
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-adjustment.html#details

On Wed, Oct 11, 2023, 15:45 Brian Rosmaita <rosmaita.fossdev at 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-commands
> [1]
>
> https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests
> [2] https://review.opendev.org/c/openstack/requirements/+/884564
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20231011/6d667598/attachment.htm>