Re: Timing of Python upstream and Debian releases
On 7/6/20 9:04 PM, Matthias Klose wrote: > 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. This looks reasonable, thanks for opening the discussion and doing the hard work. However, I wouldn't be for shipping 2 supported versions, and would prefer if we could have only one if possible, as otherwise this means running unit tests at build time against 2 python versions, which then takes twice as much build time: that's annoying and useless (because at the end, only one of these versions will be in use). Cheers, Thomas Goirand (zigo)
Re: Timing of Python upstream and Debian releases
Hi, po 6. 7. 2020 v 21:04 odesílatel Matthias Klose napsal: > 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. > +1 for this proposal. -- Best regards Ondřej Nový
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
