[Python-Dev] PEP-0006, Bug Fix Releases

[Anthony Baxter]

This is an updated version of PEP-0006, the Bugfix Release PEP.
Unless I hear some screams, I'll be checking this into CVS. It
more accurately reflects the current state of the bugfix process.
(This has been sitting in my todo list for a while)

-------------- next part --------------
PEP: 6
Title: Bug Fix Releases
Version: $Revision: 1.10 $
Author: aahz at pobox.com (Aahz), anthony at interlink.com.au (Anthony Baxter)
Status: Active
Type: Informational
Created: 15-Mar-2001
Post-History: 15-Mar-2001 18-Apr-2001


Abstract

    Python has historically had only a single fork of development,
    with releases having the combined purpose of adding new features
    and delivering bug fixes (these kinds of releases will be referred
    to as "feature releases").  This PEP describes how to fork off
    maintenance, or bug fix, releases of old versions for the primary 
    purpose of fixing bugs.

    This PEP is not, repeat NOT, a guarantee of the existence of bug fix
    releases; it only specifies a procedure to be followed if bug fix
    releases are desired by enough of the Python community willing to
    do the work.


Motivation

    With the move to SourceForge, Python development has accelerated.
    There is a sentiment among part of the community that there was
    too much acceleration, and many people are uncomfortable with
    upgrading to new versions to get bug fixes when so many features
    have been added, sometimes late in the development cycle.

    One solution for this issue is to maintain the previous feature
    release, providing bug fixes until the next feature release.  This
    should make Python more attractive for enterprise development,
    where Python may need to be installed on hundreds or thousands of
    machines.


Prohibitions

    Bug fix releases are required to adhere to the following restrictions:

    1. There must be zero syntax changes.  All .pyc and .pyo files
       must work (no regeneration needed) with all patch releases
       forked off from a feature release.

    2. There must be zero pickle changes.

    3. There must be no incompatible C API changes.  All extensions
       must continue to work without recompiling in all patch releases
       in the same fork as a feature release.

    Breaking any of these prohibitions requires a BDFL proclamation
    (and a prominent warning in the release notes).

Not-Quite-Prohibitions

    Where possible, bug fix releases should also:

    1. Have no new features. The purpose of a bug fix release is to 
       fix bugs, not add the latest and greatest whizzo feature from
       the HEAD of the CVS root.

    2. Be a painless upgrade. Users should feel confident that an
       upgrade from 2.x.y to 2.x.(y+1) will not break their running
       systems. This means that, unless it is necessary to fix a bug,
       the standard library should not change behaviour, or worse yet,
       APIs.

Helping the Bug Fix Releases Happen

    Here's a few pointers on helping the bug fix release process along.

    1. Backport bug fixes. If you fix a bug, and it seems appropriate,
       port it to the CVS branch for the current bug fix release. If
       you're unwilling or unable to backport it yourself, make a note
       in the commit message.

    2. If you're not sure, ask. Ask the person managing the current bug
       fix releases if they think a particular fix is appropriate.

    3. If there's a particular bug you'd particularly like fixed in a
       bug fix release, jump up and down and try to get it done. Do not
       wait until 48 hours before a bug fix release is due, and then
       start asking for bug fixes to be included.

Version Numbers

    Starting with Python 2.0, all feature releases are required to have
    a version number of the form X.Y; patch releases will always be of
    the form X.Y.Z.

    The current feature release under development is referred to as
    release N; the just-released feature version is referred to as N-1.

    In CVS, the bug fix releases happen on a branch. For release 2.x,
    the branch is named 'release2x-maint'. For example, the branch for
    the 2.3 maintenance releases is release23-maint


Procedure

    The process for managing patch releases is modeled in part on the cl
    Tsystem [1].

    The Patch Czar is the counterpart to the BDFL for patch releases.
    However, the BDFL and designated appointees retain veto power over
    individual patches.

    As individual patches get contributed to the feature release fork,
    each patch contributor is requested to consider whether the patch is
    a bug fix suitable for inclusion in a patch release. If the patch is
    considered suitable, the patch contributor will mail the SourceForge
    patch (bug fix?) number to the maintainers' mailing list.

    In addition, anyone from the Python community is free to suggest
    patches for inclusion. Patches may be submitted specifically for
    patch releases; they should follow the guidelines in PEP 3 [2].
    In general, though, it's probably better that a bug in a specific
    release also be fixed on the HEAD as well as the branch.

    The Patch Czar decides when there are a sufficient number of patches
    to warrant a release. The release gets packaged up, including a
    Windows installer, and made public. If any new bugs are found, they
    must be fixed immediately and a new patch release publicized (with
    an incremented version number).

    Bug fix releases are expected to occur at an interval of roughly
    six months. This is only a guideline, however - obviously, if a
    major bug is found, a bugfix release may be appropriate sooner. In
    general, only the N-1 release will be under active maintenance at
    any time. That is, during Python 2.4's development, Python 2.3 gets
    bugfix releases.


Patch Czar History

    Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4.

    Barry Warsaw is the Patch Czar for 2.2.3.

    Guido van Rossum is the Patch Czar for 2.2.2.

    Michael Hudson is the Patch Czar for 2.2.1.

    Anthony Baxter is the Patch Czar for 2.1.2 and 2.1.3.

    Thomas Wouters is the Patch Czar for 2.1.1.

    Moshe Zadka is the Patch Czar for 2.0.1.


History

    This PEP started life as a proposal on comp.lang.python.  The
    original version suggested a single patch for the N-1 release to
    be released concurrently with the N release.  The original version
    also argued for sticking with a strict bug fix policy.

    Following feedback from the BDFL and others, the draft PEP was
    written containing an expanded patch release cycle that permitted
    any previous feature release to obtain patches and also relaxed
    the strict bug fix requirement (mainly due to the example of PEP
    235 [3], which could be argued as either a bug fix or a feature).

    Discussion then mostly moved to python-dev, where BDFL finally
    issued a proclamation basing the Python patch release process on
    Tcl's, which essentially returned to the original proposal in
    terms of being only the N-1 release and only bug fixes, but
    allowing multiple patch releases until release N is published.

    Anthony Baxter then took this PEP and revised it, based on 
    lessons from the 2.3 release cycle.

References

    [1] http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html

    [2] PEP 3, Guidelines for Handling Bug Reports, Hylton
        http://www.python.org/peps/pep-0003.html

    [3] PEP 235, Import on Case-Insensitive Platforms, Peters
        http://www.python.org/peps/pep-0235.html


Copyright

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: