Python minimum version compatibility

[TurboTurtle]

As a project sos has traditionally lagged behind upstream python by quite some margin. This is due to the nature of us being a diagnostic tool and the fact that we are deployed to mostly long-life environments that have commercial support contracts. In short, vendors typically don't update the version of python that a specific version of their OS release originally shipped with, so we have to stay on that older version.

In #3505 the discussion came to this a couple times - we are still developing mainly for python-3.6, which has been EOL since the end of 2021. We went to 3.6 because in sos-4.0 we dropped python2 support and 3.6 was a commonly supported version between the RHEL and Ubuntu versions of the day - that being RHEL 8 and Ubuntu 18.04. This was done by shunting the python2-compatible tree to the legacy-3.9 branch, and saying any downstreams that still need updates to python2-compatible sos (I think even then this was just RHEL 7?) could source from there (or, just do downstream patching as needed).

I'd like to come up with a plan to move our minimum python version forward to something more modern. Ideally I'd say this means at least python-3.9, but @dnegreira recently informed me in the #3505 discussion that Ubuntu 20.04 runs python-3.8, which throws a wrench in there. That said, python-3.8 does include the support for walrus operators (:=) which is actually one of the bigger things I've been looking forward to when getting off of python-3.6.

With that context laid, lets figure out an acceptable path forward for:

1. First getting off python-3.6 and on to either 3.8 or 3.9 if possible.
2. If not possible to go to 3.9 immediately, determine a schedule for that move.
3. Put something on the roadmap for moving on from 3.9 to a reasonably recent release like 3.12 or 3.13, dependent on what downstreams anticipate the use of in X amount of time.

This basically boils down to:

• @arif-ali when can 18.04 accept being built from a legacy branch with select backports?
• @pmoravec when can RHEL 8 accept being built from a legacy branch with select backports?

[arif-ali]

For reference below are the version numbers for our OSs

python3	ubuntu	standard support till	security maintenance
3.4.0	12.04	May 2019	May 2026
3.5.1	16.04	May 2021	May 2028
3.6.7	18.04	May 2023	May 2030
3.8.2	20.04	May 2025	May 2032
3.10.6	22.04	May 2027	May 2034
3.12.3	24.04	May 2029	May 2036

On the basis of testing of 18.04. At the moment the basis of these is the snap, and actually is built python 3.10.

Now, when 24.04 comes out, the new base core24 will come available with python 3.12, and hence could be that using the base may cause 18.04 to not usable. I only created an internal ticket to discuss this already today, with the potential of having legacy tracks for old release support. Need to test this scenario, if it works, then great, and we can continue the testing.

I would say though, that it would be safe to cutofff 3.6 as per @dnegreira's comment in the issue. Once either of 4.5.6 or 4.7.0 has been released for 18.04, we will likely only concentrate on security fixes, if any come across in the new legacy branch and reported by users.

When 24.04 comes out in April, there will be some work that both me and David will be doing, such as new gce images for both latest, deb and snap testing, new snap base.

[pmoravec]

I plan to reply here from Red Hat point of view, just getting the details so far. Stay tuned.

[pmoravec]

Similar situation with RHEL, where RHEL8 is granted to run Python 3.6 (with optional 3.[8|9|11] via AppStream) and extended life support ends 2032. I havent found if/when 3.12 will be an option in AppStream to test it in GCE images on RHEL/CentOS, let me know if I should investigate more.

I expect we will drop 3.6 support in sos upstream much sooner than in 2032 :) and since that Python version is quite widely used (not only in/by RH), we should have a legacy-py3.6 branch. But let discuss that once there will be a requirement to drop 3.6 support in upstream.

[TurboTurtle]

Any movement?

[pmoravec]

I am not sure what the question / action point to me is. If "when Python 3.12 will be available on RHEL8/RHEL9 or CentOS 8/9 for sos CI tests coverage, then since 8.10/9.4 - python3.12 package is in both beta versions.

[TurboTurtle]

More of, when can we transition RHEL 8 to a legacy branch, allowing main to go to 3.9? I don't think we'd be able to go to 3.12, though with EL9? Isn't 3.9 the base standard for the life of RHEL 9, with 3.12 being provided via AppStream for customers who elect to install that alongside (rather than replacing) 3.9?

[pmoravec]

Ah I see, I got it.

Yes, RHEL9 is shipped with Python 3.9 as the base and higher versions in AppStream only. So bumping minimal Python version to (at most) 3.9 is our correct requirement.

About RHEL8: its full support ends in 2 months by delivering RHEL8.10 (https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates). I would like to get there at least one further sos tag (I shall create the 4.7.1 tag probably next week), then no strict need.

Splitting legacy-py3.6 (or whatever we call it) any time after 4.7.1 is fine for us, though I think it makes sense to align it with "Y-stream tag" of sos - i.e. the legacy branch frozen on 4.8.0 (but as I am writing this, I realize we did it the other way with legacy-3.9 and 4.0 so whatever fits better, alongside with the work that would require the 3.6 drop in upstream).

[arif-ali]

Hey @TurboTurtle we're (from Canonical) happy to drop 3.6 now, but we should only be going to 3.8. Otherwise we'll lose support for 20.04, and we (at Canonical), may need to start cherry-picking and fixing patches for 20.04 (and have a potential side fork) if upstream decided to go for 3.9. At least based on the table I provided above

[TurboTurtle]

@pmoravec ack, thanks for the input. I'm good with waiting til 4.8.0 to make the cut, i.e. 4.8.0 will still be python-3.6, and anything else after that (upstream) release cut is good for 3.8. From there on we can say 3.8 is our minimum version, per @arif-ali's matrix for Canonical, and we can look at moving to 3.9 minimum after March 2025, if I'm understanding @arif-ali correctly.

[arif-ali]

sounds good to me, it's May 2025 :). For us we would be happy to move to 3.10 at the time, but that would then depend on the RH folks and what the matrix holds of versions