Timing of Python upstream and Debian releases
Starting with Python 3.8, Python upstream changed to a time based yearly release
schedule, targeting the first release of a major Python version (3.x) for
October of each year. For the transition to 3.8:
- we add 3.8 as supported in November
- made 3.8 the default in March
- dropped 3.7 in April
That's a little bit late looking at the Debian release schedule, so a little
speedup would be needed if we want to target the current Python release for the
current Debian release. For 3.8 Ubuntu started to prepare the switch a bit
earlier, using the results for a better experience in Debian:
- added 3.8 in mid October
- made 3.8 the default in mid December
Technically it would be possible to do the defaults change before the Debian
freeze, however there's usually a tail of follow-up upstream releases required
to support a new major Python version, unless you opt for actively backporting
changes in various packages. Having the confidence, that the switch is feasible
in another distro certainly helps doing the transition in Debian, however it
adds a delay. I don't think it's feasible to do the transition in experimental
first, or doing a large test rebuild, because it requires keeping the whole
python stack in sync with testing/unstable.
So what I'm proposing here is to aim to support 3.9 as early as possible as a
supported Python3 version, starting with the 3.9 upstream release, and fixing
stuff on the go. Then decide in November, if we can do the defaults change to
3.9, or if we drop 3.9 again, or ship with two supported Python3 versions.
Please note this will be a re-occuring situation with Python 3.11 and
bullseye+1, so we should find out how to handle this on a regular basis,
assuming that Debian release schedules won't change much.
Matthias
Reply to: