On 6 July 2016 at 05:11, Brett Cannon <br...@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 between: * 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 release. 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
