python_requires >= 3.8 during Yoga

Clark Boylan cboylan at
Wed Dec 1 18:06:16 UTC 2021

On Wed, Dec 1, 2021, at 9:31 AM, Alex Schultz wrote:
> On Wed, Dec 1, 2021 at 10:05 AM Sean Mooney <smooney at> wrote:

Apologies if my reduction of thread content was too aggressive.

>> so haveing at least 3.9  support in yoga will be imporatn for multiple distros and to help use test that i and proably others
>> suggested raising the minium python version to 3.8 so that we only have to test with 2 version in the gate instead of 3.(3.6 3.8 and 3.9)
>> continuting to support py36 aslo puts a burden on developers not just on our ci infrastucre as it will becomre harder to test wtih going froward
>> as it stops being shipped in distros and as it exits security support
>> the end of life for python 3.6 is planned for this month
>> speficically (23 Dec 2021) based on
>> i dont think we shoudl be releasing yoga on an end of life python version.
>> if we raise the minium to 3.8 that will be supported until at least 14 Oct 2024
>> which is after the stabel branch will be retired.
> So I guess the question is who do we use for language support EOLs?
> My understanding is that Ubuntu 18.04's default was 3.6 which has
> standard support until 2023[0] and CentOS Stream 8 will be supported
> until 2024[1].  Both of which should exceed Yoga's support[2]?  With
> all these arguments about LTS distros, it seems that we should be
> using their support life cyles for the language versions and not
> python's[3].
> [0]
> [1]
> [2]
> [3]

I'd like to make a proposal for moving forward. But first let's summarize some facts so that we can evaluate the proposal against the state of the world.

* Python 3.6 reaches EOL soon.
* CentOS 9 Stream is released and makes no mention of being in a beta status (
* We have the ability to run tests on CentOS 9 Stream today
* It is useful to users to ensure we have an OpenStack release tested against old distro release with old python and new distro release with new python. This enables them to update underlying distro releases independently from upgrading OpenStack.
* The various distros are not in sync over which python versions they support.

Given this state it seems reasonable that we continue to test Yoga against python3.6 and newer python. It would also probably be a good idea to explicitly update the PTI and distro support policies to indicate that when adding new distro releases we continue to support the old distro release's python for one cycle. The level of actual testing done on these platforms will depend on who steps up to maintain that testing, but at the very least we'll accept bug fixes for old python and not prevent installation via setup.cfg python_requires settings.

Yes, this means another cycle of python3.6 support which isn't ideal given it's soon EOL, but the intent is to support distros who will continue to support the older python on their platform.

If we want to be bold and try an experiment, we could also reduce testing of the python versions to oldest and newest supported python versions. For example python3.6 and python3.9 during Yoga. Don't worry about python3.7 and python3.8 as it is likely they will continue to function as long as 3.6 and 3.9 are happy. This would reduce the size of the testing matrix. We can always reevaluate if problems for 3.7 and 3.8 occur.

Finally, I think it is important to note that OpenStack is using CentOS as a stand in for RHEL. This worked a lot better when CentOS was an actual copy of RHEL. What we've got today is CentOS stream and it makes no claims about being in beta until RHEL releases (that I can find anyway), and I don't think we should make those assertions ourselves. If there is interest in using a different stand in (Alma or Rocky?) then we should replace CentOS stream with one of those alternatives. Another option may be to assert that Stream only functions as a standin once RHEL has released their corresponding update, but it is my understanding that Stream and RHEL will always have some delta.


More information about the openstack-discuss mailing list