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

[Dirkjan Ochtman]

On Tuesday, January 17, 2012, Antoine Pitrou <solipsis at pitrou.net> wrote:
> We would like to propose the following PEP to change (C)Python's release
> cycle. Discussion is welcome, especially from people involved in the
> release process, and maintainers from third-party distributions of
> Python.

As a Gentoo packager, this would mean much more work for us, unless all the
non-LTS releases promised to be backwards compatible. I.e. the hard part
for us is managing all the incompatibilities in other packages,
compatibility with Python.

As a user of Python, I would rather dislike the change from 18 to 24 months
for LTS release cycles. And the limiting factor for my use of Python
features is largely old Python versions still in use, not the availability
of newer features in the newest Python. So I'm much more interested in
finding ways of improving 2.7/3.2 uptake than adding more feature releases.
I also think that it would be sensible to wait with something like this
process change until the 3.x adoption curve is much further along.

Cheers,

Dirkjan




> Regards
>
> Antoine.
>
>
> PEP: 407
> Title: New release cycle and introducing long-term support versions
> Version: $Revision$
> Last-Modified: $Date$
> Author: Antoine Pitrou <solipsis at pitrou.net>,
>        Georg Brandl <georg at python.org>,
>        Barry Warsaw <barry at python.org>
> Status: Draft
> Type: Process
> Content-Type: text/x-rst
> Created: 2012-01-12
> Post-History:
> Resolution: TBD
>
>
> Abstract
> ========
>
> Finding a release cycle for an open-source project is a delicate
> exercise in managing mutually contradicting constraints: developer
> manpower, availability of release management volunteers, ease of
> maintenance for users and third-party packagers, quick availability of
> new features (and behavioural changes), availability of bug fixes
> without pulling in new features or behavioural changes.
>
> The current release cycle errs on the conservative side.  It is
> adequate for people who value stability over reactivity.  This PEP is
> an attempt to keep the stability that has become a Python trademark,
> while offering a more fluid release of features, by introducing the
> notion of long-term support versions.
>
>
> Scope
> =====
>
> This PEP doesn't try to change the maintenance period or release
> scheme for the 2.7 branch.  Only 3.x versions are considered.
>
>
> Proposal
> ========
>
> Under the proposed scheme, there would be two kinds of feature
> versions (sometimes dubbed "minor versions", for example 3.2 or 3.3):
> normal feature versions and long-term support (LTS) versions.
>
> Normal feature versions would get either zero or at most one bugfix
> release; the latter only if needed to fix critical issues.  Security
> fix handling for these branches needs to be decided.
>
> LTS versions would get regular bugfix releases until the next LTS
> version is out.  They then would go into security fixes mode, up to a
> termination date at the release manager's discretion.
>
> Periodicity
> -----------
>
> A new feature version would be released every X months.  We
> tentatively propose X = 6 months.
>
> LTS versions would be one out of N feature versions.  We tentatively
> propose N = 4.
>
> With these figures, a new LTS version would be out every 24 months,
> and remain supported until the next LTS version 24 months later.  This
> is mildly similar to today's 18 months bugfix cycle for every feature
> version.
>
> Pre-release versions
> --------------------
>
> More frequent feature releases imply a smaller number of disruptive
> changes per release.  Therefore, the number of pre-release builds
> (alphas and betas) can be brought down considerably.  Two alpha builds
> and a single beta build would probably be enough in the regular case.
> The number of release candidates depends, as usual, on the number of
> last-minute fixes before final release.
>
>
> Effects
> =======
>
> Effect on development cycle
> ---------------------------
>
> More feature releases might mean more stress on the development and
> release management teams.  This is quantitatively alleviated by the
> smaller number of pre-release versions; and qualitatively by the
> lesser amount of disruptive changes (meaning less potential for
> breakage).  The shorter feature freeze period (after the first beta
> build until the final release) is easier to accept.  The rush for
> adding features just before feature freeze should also be much
> smaller.
>
> Effect on bugfix cycle
> ----------------------
>
> The effect on fixing bugs should be minimal with the proposed figures.
> The same number of branches would be simultaneously open for regular
> maintenance (two until 2.x is terminated, then one).
>
> Effect on workflow
> ------------------
>
> The workflow for new features would be the same: developers would only
> commit them on the ``default`` branch.
>
> The workflow for bug fixes would be slightly updated: developers would
> commit bug fixes to the current LTS branch (for example ``3.3``) and
> then merge them into ``default``.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120118/53142c6a/attachment.html>