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

Barry Warsaw barry at python.org
Tue Jul 5 13:44:49 EDT 2016

On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote:

>While we liked the "consistent calendar cadence that is some multiple
>of 6 months" idea, several of us thought 12 months was way too short
>as it makes for too many entries in third party support matrices.

18 months for a major release cadence still seems right to me.  Downstreams
and third-parties often have to go through *a lot* of work to ensure
compatibility, and try as we might, every Python release breaks *something*.
Major version releases trigger a huge cascade of other work for lots of other
people, and I don't think shortening that would be for the overall community
good.  It just feels like we'd always be playing catch up.

Different downstreams have different cadences.  I can only speak for Debian,
which has a release-when-ready policy, and Ubuntu, which has strictly timed
releases.  When the Python release aligns nicely with Ubuntu's LTS releases,
we can usually manage the transition fairly well because we can allocate
resource way ahead of time.  (I'm less concerned about Ubuntu's mid-LTS 6
month releases.)

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.

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.


More information about the Python-Dev mailing list