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
On Fri, May 27, 2022 at 6:07 AM Miro Hrončok mhroncok@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?
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.
On 27. 05. 22 14:34, Neal Gompa wrote:
While unfortunate, I think it makes sense to retire Python 3.7 when Debian 10 goes EOL.
I don't understand why do you consider this unfortunate.
I think the larger question is how do we write down a multi-Python maintenance policy to codify this?
It has been so far implicitly (but indeed not written) somehow like this:
"We keep a Python version in Fedora as long as:
1) A "significant enough" platform that our users could be deploying into runs that Python version. That has always been at least RHEL, Debian and Ubuntu LTS.
2) It is bearable for the maintainers."
1 means we drop it when it's no longer useful. 2 means we drop when we cannot longer make it work with the current resources.
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.
At least for RHEL, we still use Fedora as upstream for our patches. So as long as a Python is supported in RHEL, we would (in most cases) try to fix Fedora together with RHEL.
For upstream EOLed Pythons that are not in RHEL but are supported in other distros (e.g. Python 3.7 will be supported in Debian for ~1 additional year after upstream EOL, but is not included in RHEL), we don't know yet (it never happened until now).
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).
Not necessarily my goal, but a nice goal nevertheless.
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.
Making it easier to use Fedora when you target those distributions was my primary goal here.
On Fri, May 27, 2022 at 11:35 AM Miro Hrončok mhroncok@redhat.com wrote:
On 27. 05. 22 14:34, Neal Gompa wrote:
While unfortunate, I think it makes sense to retire Python 3.7 when Debian 10 goes EOL.
I don't understand why do you consider this unfortunate.
The situation is unfortunate, not the result.
I think the larger question is how do we write down a multi-Python maintenance policy to codify this?
It has been so far implicitly (but indeed not written) somehow like this:
"We keep a Python version in Fedora as long as:
- A "significant enough" platform that our users could be deploying into runs
that Python version. That has always been at least RHEL, Debian and Ubuntu LTS.
- It is bearable for the maintainers."
1 means we drop it when it's no longer useful. 2 means we drop when we cannot longer make it work with the current resources.
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.
At least for RHEL, we still use Fedora as upstream for our patches. So as long as a Python is supported in RHEL, we would (in most cases) try to fix Fedora together with RHEL.
For upstream EOLed Pythons that are not in RHEL but are supported in other distros (e.g. Python 3.7 will be supported in Debian for ~1 additional year after upstream EOL, but is not included in RHEL), we don't know yet (it never happened until now).
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).
Not necessarily my goal, but a nice goal nevertheless.
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.
Making it easier to use Fedora when you target those distributions was my primary goal here.
Makes sense to me.
On 27. 05. 22 12:07, Miro Hrončok wrote:
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".
Thanks for all the answers.
I've created https://fedoraproject.org/wiki/Changes/RetirePython3.7
python-devel@lists.fedoraproject.org
-
Miro Hrončok -
Neal Gompa