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

Nick Coghlan ncoghlan at gmail.com
Wed Jan 18 12:26:19 CET 2012

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

  1. 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)

  2. 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

  3. 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.

More information about the Python-Dev mailing list