In that discussion, I myself wrote: "I expect we have Plone 6.0 before October". That was in 2021. We are now almost one year later. So it is time to reconsider which Python versions we want to support.
Which Python versions should Plone 6.0 final support?
Some considerations against dropping:
Plone 6.0 is already in beta status, so it would not be nice to drop support.
Python 3.7 and 3.8 are still supported by the Python community, although only for security updates. See active Python releases.
Some considerations for dropping:
Testing Plone on multiple Python versions takes time, space and energy on our testing infrastructure.
Every year in October a new minor Python release is done. Two years from now we might need to support Python 3.7-3.12, which is really too much.
Python 3.7 is end-of-life in June next year already. So Plone 6.0 can only reasonably be supported for this Python version for about nine months, which is much shorter than we want.
Python support for 3.9 ends in October 2025, so in about three years. That means at least three years of bug fix and security support for Plone 6.0 without worries from the Plone Release Team and Security Team.
It takes real effort from the release team and other core contributors to keep Plone running on all those Python versions. Consider an upstream package that drops support for a Python version. We need to notice that that it no longer works, and keep a longer and longer list of different versions of this package to use in different Python versions.
One question is if Python 3.9 is supported by the most used Linux distributions. In the discussion @ale-rt made a script to check Python versions in 100 popular distros. It seems correct to me. Adapting it, I see that these distros support 3.7 but not 3.8 in their latest release:
The only reason I can see to support Python 3.8 is to provide a bridge for people who want to upgrade from Plone 5.2, which supports only up to Python 3.8 according to its trove classifiers, but not Python. Else I would drop Python 3.8. In reality, this might not even be a thing to be concerned about.
Adding support for a new version of python does add some maintenance and code adapting cost, but anyway we want to support new versions of python whenever they come.
On the other hand, keeping support for old python releases it makes only sense as long as they are supported, so IMHO I would not actively drop support for them, but stop testing and fixing code for older versions as soon as Python support stops, so if Plone 6 works with python 3.7 all fine and dandy, but when its end-of-life is June 2023 I would stop considering it supported on Plone 6.
Fortunately new python 3 releases are mostly incremental, so jumping from 3.7 to 3.8 is not a major undertaking as it has been from python 2 to python 3, so asking maintainers to update their python 3 version from 3.7 to 3.8/3.9/3.10/3.11 by the time of 3.7 end-of-life is not such a dramatic undertake I would say.
Finally we have to consider our dependencies, what's Zope policy on that? What about our long tail of dependencies? It might be easier to get new releases to support new versions, but keeping special pins for outdated versions on a given python release takes time and can introduce security problems as well.
Does it make sense to drop support on a python release because dependency XYZ has a security problem only fixed on a newer release only supported on newer python versions?
About linux distributions, given that nowadays it is so easy to get containers, and other abstraction layers between the OS and the running service I would consider it a minor detail. Plone is already creating its own official docker images, right?
Oh my, thinks do get complex once you dive into them
Since the foundation of Plone is Zope, the supported Python versions by Zope are the ones that matter. If some Python version is not supported by Zope, Plone can not provide support for such a Python version.
My 2 cents: restrict the supported Python versions to the latest official Python releases. I assume that would be Python 3.11 and 3.10 at the time of the official Plone 6.0.0 release. For new projects, I usually want to use a decent Python version. As a developer of Plone add-ons, I possibly want to make use of newer Python features (for whatever reason). As a developer of Plone add-ons for Plone 6, I want to ensure that my add-on works on Plone 6.0 installation. That means I must be sure that all Plone 6.0 installations run a decent version of Python (without having the need to support older versions in add-ons).
We discussed this in the Plone 6 coordination meeting today.
My current feeling: drop 3.7. Keep 3.8 for now. It is still supported for two more years by the Python community.
I hope to release beta 2 within a few days, and will add it to the release notes.
Here is a list of new features in 3.8. This includes positional-only arguments, assignment expressions (the 'walrus' operator :=), f-strings support a handy = specifier for debugging , continue is now legal in finally: blocks.
Here is a list of new features in 3.9. This includes adding union operators to dict, and adding string methods to remove prefixes and suffixes.
For me, it is not so much "hey we can now use extra cool stuff", but more: I don't want to test and support Plone on five different Python versions in the near future.
There is probably a ton of code in Plone (and Zope) that could benefit from new Python syntax and features, but we are probably still not using some new possibilities from say Python 3.4.
I think for Plone 6.1 (which is a long way off) we should make it clear from the start that we only support a limited number of Python versions, and that we will pick the definitive list during the beta phase. Gut feeling: if we release Plone 6.1 one year from now, we should support 3.10 and 3.11. We may be seeing more minor Plone versions in the future, and for some versions the only major change would be that we drop a Python version.
Also: if Plone 6.0 survives longer than Python 3.8, we will drop support for it anyway, although we will not actively break it by using too new syntax/features.
@mauritsvanrees really? I would drop 3.8 - not because in 3.9 there are no new features (except it is faster than 3.8). More because soon we have 3.11, then soon we want to support it (ASAP, performance improvements are coming). And with 3.8-.11 we again have 4 versions to test on.
I do not see any good reason why we need to support 3.8 for Plone 6.
At least for add-ons under my control I am already 3.9/3.10 only and will add 3.11 as soon as it is released.
My few Plone 6 hostings are already 3.10 only, because there is no reason to not use the freshest and fastest (!) Python release.
Enforcing an efficient Python version also helps reducing the environmental footprint of Plone. Nice side effect: It makes the users happy too.
This means if you have a current Ubuntu (not latest though) you might have to stick with Python 3.8 for a while.
In the end, it is a decision that the release team and the CI team have to make IMHO since they are the people who have to put all the effort into supporting multiple versions. Therefore the decision is rather bound to what this group of people is willing and capable of doing.
The installer can install its own version of Python. The only case is when using the system python to do a virtualenv (which the installer can do), but with pyenv or other tools installing different python versions is quite easy and you need dev libraries anyway to install Plone.
Also, python 3.9 is available in Ubuntu 20.4:
Installing Python is something the installer shouldn't do, we can link to various sources/link/best practices to do it, imho.
But you're certainly correct that the decision is with the team that worked on supporting multiple versions.
We have a desktop build of ubuntu 22.02 with Python 3.10 installed by default that is not 'ready' for prime time. (yay! new hires to experiment on!) Lots of issues. Plus, Plone 5 was a problem because it's not ready for Python 3.10 yet, at least for us.
So yeah. I'll jump on the Ubuntu 20.02 == python 3.8 argument.
and warn against Ubuntu 22.02 at this time.