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

Nick Coghlan ncoghlan at gmail.com
Tue Jul 5 20:02:06 EDT 2016


On 6 July 2016 at 03:44, Barry Warsaw <barry at python.org> wrote:
> For example, 3.6 final will come out in December 2016, so it'll be past our
> current 16.10 Ubuntu release.  We've pretty much decided to carry Python 3.5
> through until 17.04, and that'll give us a good year to make 18.04 LTS have a
> solid Python 3.6 ecosystem.

This aligns pretty well with Fedora's plans - the typical Fedora
release dates are May & November, so we will stick with 3.5 for this
year's F25 release, while the Fedora 26 Rawhide branch is expected to
switch to 3.6 shortly after the first 3.6 beta is released in
September. The results in Rawhide should thus help with upstream 3.6
beta testing, with the full release of F26 happening in May 2017 or
so.

> Projecting ahead, it probably means 3.7 in mid-2018, which is after the Ubuntu
> 18.04 LTS release, so we'll only do one major transition before the next LTS.
> From my perspective, that feels about right.

Likewise - 24 months is a bit too slow in getting features out, 12
months expands the community version support matrix too much, while 18
months means that even folks supporting 5* year old LTS Linux releases
will typically only be a couple of releases behind the latest version.

Cheers,
Nick.

* For folks that don't closely follow the way enterprise Linux distros
work, the '5' there isn't arbitrary - it's the lifecycle of Ubuntu LTS
releases, and roughly the length of the "Production 1" phase of RHEL
releases (where new features may still be added in point releases).
Beyond the 5 year mark, I don't think it's particularly reasonable for
people to expect free community support, as even Red Hat stops
backporting anything other than bug fixes and hardware driver updates
at that point. Regardless of your choice of LTS platform, newer
versions will be available by the time your current one is that old,
so "I don't want to upgrade" is a privilege people can reasonably be
expected to pay for.

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


More information about the Python-Dev mailing list