[Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

Nick Coghlan ncoghlan at gmail.com
Tue Jul 5 20:55:18 EDT 2016

On 6 July 2016 at 05:11, Brett Cannon <brett at python.org> wrote:
> Sticking w/ 18 months is also fine, but then I would like to discuss
> choosing what months we try to release to get into a date-based release
> cadence so we know that every e.g. December and June are when releases
> typically happen thanks to our 6 month bug-fix release cadence. This has the
> nice benefit of all of us being generally aware of when a bug-fix release is
> coming up instead of having to check the PEP or go through our mail archive
> to find out what month a bug-fix is going to get cut (and also something the
> community to basically count on).

I don't have a strong preference on that front, as even the worst case
outcome of a schedule misalignment for Fedora is what's happening for
Fedora 25 & 26: F25 in November will still have Python 3.5, while
Rawhide will get the 3.6 beta in September or so and then F26 will be
released with 3.6 in the first half of next year.

So really, I think the main criterion here is "Whatever works best for
the folks directly involved in release management"

However, if we did decide we wanted to take minimising "time to
redistribution" for at least Ubuntu & Fedora into account, then the
two main points to consider would be:

- starting the upstream beta phase before the first downstream alpha freeze
- publishing the upstream final release before the last downstream beta freeze

Assuming 6 month distro cadences, and taking the F25 and 16.10 release
cycles as representative, we get:

- Ubuntu alpha 1 releases in late January & June
- Fedora alpha freezes in early February & August
- Ubuntu final beta freezes in late March & September
- Fedora beta freezes in late March & September

Further assuming we stuck with the current model of ~3 months from
beta 1 -> final release, that would suggest a cadence alternating

* December beta, February release
* May beta, August release

If we did that, then 3.6 -> 3.7 would be another "short" cycle (15
months from Dec 2016 to Feb 2018) before settling into a regular
cadence of:

* 2017-12: 3.7.0b1
* 2018-02: 3.7.0
* 2019-05: 3.8.0b1
* 2019-08: 3.8.0
* 2020-12: 3.9.0b1
* 2021-02: 3.9.0
* 2022-05: 3.10.0b1
* 2022-08: 3.10.0
* etc...

The precise timing of maintenance releases isn't as big a deal (since
they don't require anywhere near as much downstream coordination), but
offsetting them by a month from the feature releases (so March &
September in the Fedbuntu driven proposal above) would allow for the
X.(Y+1).1 release to go out at the same time as the final X.Y.Z

I'll reiterate though that we should be able to adjust to *any*
consistent 18 month cycle downstream - the only difference will be the
typical latency between new versions being released on python.org, and
them showing up in Linux distros as the system Python installation.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list