[Python-ideas] Proposal to change Python version release cycle

Nick Coghlan ncoghlan at gmail.com
Sat Nov 4 10:48:33 EDT 2017

On 4 November 2017 at 23:29, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Hello Wolfgang,
> On Sat, 4 Nov 2017 12:25:57 +0100 (CET)
> tds333 at mailbox.org wrote:
>> Hello,
>> one of my long standing ideas to improve Python is to adjust the
>> release cycle and version number handling. In short, to simplify it.
> There has been ample discussion in the past about changing our release
> cycle one way or another. In short, the meta-problem is there are many
> contradicting interests which would each favour a different solution to
> the problem.  See for example this PEP (ultimately rejected):
> https://www.python.org/dev/peps/pep-0407/
> and the discussion that ensued:
> https://mail.python.org/pipermail/python-dev/2012-January/thread.html#115591

PEP 413 was another competing proposal from around the same time:

Technically neither proposal has been formally Rejected, but they're
also Deferred/Withdrawn because we knew that if we *had* asked for an
explicit determination, the answer would have been "No, too high a
cost, for not enough of a demonstrated benefit" (and that hasn't
really changed in the past 5 years).

> I haven't read your proposal in detail, but I suspect that it may be
> vulnerable to some of the same objections.  The big objection being
> that a significant part of our ecosystem (that is, to put it roughly,
> the more corporate-minded segment, though I believe it is a
> simplification and may include other segments, such as Debian stable
> users and maintainers) doesn't want to deal more frequent feature
> releases.

It's not just redistributors that get affected - it's the
compatibility testing matrices for community projects as well.

With our current release cycles (and excluding the 2.7 LTS release
from consideration) we tend to have the following situation for the
3.x branches:

- 1 actively maintained version
- 2 or 3 security-fix only branches

This stems from the default commitment of security fixes ending around
5 years after an X.Y.0 release, and releases happening 18-24 months

* Month 0: X.Y.0 released
* Month 18: X.(Y+1).0 released
* Month 36: X.(Y+2).0 released
* Month 54: X.(Y+3).0 released
* Month 60: X.Y.Z goes end-of-life
* Month 72: X.(Y+4).0 released

That same pattern also held for the 2.x series until the 2.7 release
in 2010 (and it only changed then because that was the last 2.x
feature release).

The current year or so where the number of supported branches drops
down to only 3 means we have some scope to speed up the rate of
feature releases a bit (i.e. a release cadence of every 15 months
instead of every 18 still means the community compatibility testing
matrix consistently stays around 4 versions, or 5 if you're also
testing against the dev release), but going to 6 monthly version
updates means folks will either keep their test matrices the same as
they are now (increasing the odds of the standard-library-only updates
breaking things and that not being detected for some time), or else
feeling obliged to expand their test matrices to cover even more
concurrently supported versions. There are potential ways around both
of those problems, but they require making the defined support periods
for minor releases significantly shorter, unless they're the last
minor release before the next major release (which means that instead
of being simpler, these kinds of arrangements tend to end up being
*more* complicated than the "every feature release receives security
updates for 5 years" status quo).

So rather than making fundamental changes to the way Python is
versioned just to make standard library updates more readily available
on older base versions of Python, we've instead gone with a more needs
driven approach: making backport modules available for older versions
where we find it is beneficial to do so (e.g. contextlib2, unittest2,

While Python 2.7 is a major driver for that change in practice, the
benefits apply to older 3.x releases as well:

- the updated modules are available for all Python versions and
implementations where the packaging tools work (which is most of them)
- users can decide on a module-by-module basis whether they want the
baseline version or fast track updates
- those decisions are explicitly tracked in the project's dependency
metadata, rather than being implicit in the choice of deployment


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

More information about the Python-ideas mailing list