[Python-Dev] PEP 407: New release cycle and introducing long-term support versions

[Nick Coghlan]

This won't be a surprise to Antoine or Georg (since I've already
expressed the same opinion privately), but I'm -1 on the idea of
official releases of the whole shebang every 6 months. We're not
Ubuntu, Fedora, Chrome or Firefox with a for-profit company (or large
foundation) with multiple paid employees kicking around to really
drive the QA process. If we had official support from Red Hat or
Canonical promising to devote paid QA and engineering resources to
keeping things on track my opinion might be different, but that is
highly unlikely. I'm also wholly in agreement with Ezio that using the
same versioning scheme for both full releases and interim releases is
thoroughly confusing for users (for example, I consider Red Hat's
completely separate branding and versioning for Fedora and RHEL a
better model for end users than Canonical's more subtle 'Ubuntu' and
'Ubuntu LTS' distinction, and that's been my opinion since long before
I started working for RH).

My original suggestion to Antoine and Georg for 3.4 was that we simply
propose to Larry Hastings (the 3.4 RM) that we spread out the release
cycle, releasing the first alpha after ~6 months, the second after
about ~12, then rolling into the regular release cycle of a final
alpha, some beta releases, one or two release candidates and then the
actual release. However, I'm sympathetic to Antoine's point that early
alphas aren't likely to be at all interesting to folks that would like
a fully supported stdlib update to put into production and no longer
think that suggestion makes much sense on its own.

Instead, if the proposal involves instituting a PEP 3003 style
moratorium (i.e. stdlib changes only) for all interim releases, then
we're essentially talking about splitting the versioning of the core
language (and the CPython C API) and the standard library. If we're
going to discuss that, we may as well go a bit further and just split
development of the two out onto separate branches, with the current
numbering scheme applying to full language version releases and
switching to a date-based versioning scheme for the standard library
(i.e. if 3.3 goes out in August as planned, then it would be "Python
3.3 with the 12.08 stdlib release").

What might such a change mean?


1. For 3.3, the following releases would be made:
    - 3.2.x is cut from the 3.2 branch (1 rc + 1 release)
    - 3.3.0 + PyStdlib 12.08 is created from the default branch (1
alpha, 2 betas, 1+ rc, 1 release)
    - the 3.3 maintenance branch is created
    - the stdlib development branch is created

2. Once 3.2 goes into security-fix only mode, this would then leave us
with 4 active branches:
    - 2.7 (maintenance)
    - 3.3 (maintenance)
    - stdlib (Python 3.3 compatible, PEP 3003 compliant updates)
    - default (3.4 development)

The 2.7 branch would remain a separate head of development, but for
3.x development the update flow would become:
    Bug fixes: 3.3->stdlib->default
    Stdlib features: stdlib->default
    Language changes: default

3. Somewhere around February 2013, we prepare to release Python 3.4a1
and 3.3.1, along with PyStdlib 13.02:
    - 3.3.1 + PyStdlib 12.08 is cut from the 3.3 branch (1 rc + 1 release)
    - 3.3.1 + PyStdlib 13.02 comes from the stdlib branch (1 alpha, 1
beta, 1+ rc, 1 release)
    - 3.4.0a1 comes from the default branch (may include additional
stdlib changes)

4. Around August 2013 this process repeats:
    - 3.3.2 + PyStdlib 12.08 is cut from the 3.3 branch
    - 3.3.2 + PyStdlib 13.08 comes from the stdlib branch (final 3.3
compatible stdlib release)
    - 3.4.0a2 comes from the default branch

5. And then in February 2014, we gear up for a new major release:
    - 3.3.3 is cut from the 3.3 branch and the 3.3 branch enters
security fix only mode
    - 3.4.0 + PyStdlib 14.02 is created from the default branch (1
alpha, 2 betas, 1+ rc, 1 release)
    - the 3.4 maintenance branch is created and merged into the stdlib branch

(alternatively, Feb 2014 could be another interim release of 3.4 alpha
and a 3.3 compatible stdlib updated, with 3.4 delayed until August
2014)

I believe this approach would get to the core of what the PEP authors
want (i.e. more frequent releases of the standard library), while
being quite explicit in *avoiding* the concerns associated with more
frequent releases of the core language itself. The rate of updates on
the language spec, the C API (and ABI), the bytecode format and the
AST would remain largely unchanged at 18-24 months. Other key
protocols (e.g. default pickle formats) could also be declared
ineligible for changes in interim releases.

If a critical security problem is found, then additional releases may
be cut for the maintenance branch and for the stdlib branch.

There's a slight annoyance in having all development filtered through
an additional branch, but there's a large advantage in that having a
stable core in the stdlib branch makes it more likely we'll be able to
use it as a venue for collaboration with the PyPy, Jython and
IronPython folks (they all have push rights and a separate branch
means they can use it without having to worry about any of the core
changes going on in the default branch). A separate branch with
combined "3.x.y + PyStdlib YY.MM" releases is also significantly less
work than trying to split the stdlib out completely into a separate
repo.

Regards,
Nick.