Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12725 > unrolled thread

Timing of Python upstream and Debian releases

Back to article view | Back to linux.debian.maint.python

Contents

  Timing of Python upstream and Debian releases Matthias Klose <doko@debian.org> - 2020-07-06 21:10 +0200
    Re: Timing of Python upstream and Debian releases Ondrej Novy <novy@ondrej.org> - 2020-07-07 08:40 +0200
    Re: Timing of Python (3.9) upstream and Debian releases Matthias Klose <doko@debian.org> - 2020-10-12 11:50 +0200

#12725 — 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

[toc] | [next] | [standalone]

#12728

[Multipart message — attachments visible in raw view] — view raw

Hi,

po 6. 7. 2020 v 21:04 odesílatel Matthias Klose <doko@debian.org> 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ý

[toc] | [prev] | [next] | [standalone]

#12938 — Re: Timing of Python (3.9) 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.
> 
> 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.

3.9 was released last week and migrated to testing.  I did a test rebuild with
3.9 as a supported Python3 version, however not for unstable, but for the
current Ubuntu development version. Of course there is some version skew, but it
should give an idea what still needs work.

Bugs are filed at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.9;users=debian-python@lists.debian.org

which definitely looks better than the addition of 3.8 last year.

The PPAs used are based on groovy:
https://launchpad.net/~pythoneers/+archive/ubuntu/python3.9
https://launchpad.net/~pythoneers/+archive/ubuntu/python3.9-fixes

The first PPA just has no-change uploads, while the second one has some
sourceful uploads.  If you want to see some update in these PPAs, please ask
Emmanuel Arias, Graham Inggs or myself.

I'm planning to upload python3-defaults from experimental to unstable this
Wednesday (Oct 14). We will see some days of instability as we are doing the
binNMUs.

Matthias

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web