On Fri, May 27, 2022 at 6:07 AM Miro Hrončok <mhron...@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! _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
