Re: Retiring Python 3.7 before Python 3.6?
On Fri, May 27, 2022 at 6:07 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Hey Pythonistas,
let me include you in my dilemma I have wrt different Python versions we
support in Fedora for testing.
tl;dr Should we retire Python 3.7 before Python 3.6? 3.6 will stick around for
RHEL 8, but 3.7 will no longer be "needed". However, retiring mid-order might
be confusing.
Note that this topic is not urgent at all, I am just curious about what is the
best plan for the future.
Python 3.7 retirement date
==========================
Python 3.7 has security support upstream until June, 2023.
It is also used in Debian 10 “Buster” -- LST ends June, 2024.
Ubuntu seem to have skipped this Python version, so no LTS to consider there.
Same with the SUSE Linux Enterprise Server.
If nothing changes significantly, Fedora 40 will be released in April 2024,
hence the natural thing to do would be to retire Python 3.7 in Fedora 40.
(I might have made an error, evaluating the dates. Please, do correct me if
there is a significant platform that supports Python 3.7 beyond Debian 10 LTS
EOL or if some dates are wrong.)
Python 3.6 retirement date
==========================
Python 3.6 will be supported until RHEL 8 goes EOL. Which will likely not
happen until 2029 [1]. That means, we might consider retiring it in Fedora 50
(wow).
My dilemma
==========
If we retire 3.7 before 3.6, the situation will be harder to explain to our
users. Why is there a gap, they might ask. In the future, the list of supported
Python versions might look weird and contain multiple gaps as we are eventually
going to face this situation again with 3.8, 3.10...
If we keep 3.7 around until 3.6 goes down, it will be harder to maintain. If it
was just 3.7, that would probably be acceptable, but assuming no release
schedules change, we will likely have Python 3.18 in Fedora 50. That means we
would need to support 12 different Python 3.X versions by then if we haven't
started introducing those gaps. Now we support 6.
As I written this down, I think the better thing to do is to accept the gaps
and retire Python 3.7 before Python 3.6 right away and not decide to "keep it
around, as we still support both 3.6 and 3.8". WDYT?
[1] https://access.redhat.com/support/policy/updates/errata
While unfortunate, I think it makes sense to retire Python 3.7 when
Debian 10 goes EOL. I think the larger question is how do we write
down a multi-Python maintenance policy to codify this? The implicit
assumption here is that we're going to be able to leverage security
support work in other distributions to keep other Python runtimes
alive, but I don't think we've got that written down anywhere.
Moreover, we don't have anything written down for where to reference
and source security fixes across distributions for multi-Python
(assuming that's a goal here).
If we're not doing any of that, then I'm not sure why other
distributions matter for our multi-Python support beyond just making
it easier to target those distributions. And if that's true, then we
should have that codified too.
--
真実はいつも一つ！/ Always, there's only one truth!