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