- 3.14: Ubuntu 26.04
- 3.12: RHEL 10, Ubuntu 24.04
- 3.10: Ubuntu 22.04
- 3.9: RHEL 9
- 3.8: Ubuntu 20.04
- 3.6: RHEL 8 (EOL in 2029)* https://docs.redhat.com/en/documentation/red_hat_enterprise_...
As does RHEL9:
* https://docs.redhat.com/en/documentation/red_hat_enterprise_...
And "support" doesn't mean you get the same package selection as the original:
$ yum search 'python3' 2>&1 | grep '^python3-' | wc -l
1551
$ yum search 'python3' 2>&1 | egrep '^python3(8|9|\.)' | wc -l
279https://access.redhat.com/support/policy/updates/rhel-app-st...
The support lifecycles are divergent from the rest of the OS though. Only the base Python version gets full lifecycle support, the newer versions get refreshed occasionally and eventually fall out of support.
The distro may keep applying security patches to old Python versions but there are definitely limits to what's feasible. If you try to build 3.6 or earlier from source today you'll run into issues with getting an old enough OpenSSL version to be compatible (and then you're stuck with the problems of that version). Some of my old-version builds also seem to segfault whenever you try to use `ctypes` (including indirectly, which can happen in very surprising ways) and I haven't fully diagnosed that.
But developers who want to "participate in the ecosystem" are not going to have a fun time regardless, because their dependencies are not going to keep supporting older Python in newer package versions. On the other hand, your old hack scripts will usually still work in even much newer Python versions, unless you tripped on a standard library deprecation landmine or something (which generally only happens with much older stuff than the 5-year support window; see https://peps.python.org/pep-0594/ and check out the "Added in" column in the table).