PEP 6 revision

[Aahz Maruch]

[posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to
python-dev]

[Barry, please update Post-History]

Okay, here's the next version of PEP 6:

PEP: 6
Title: Bugfix Releases
Version: $Revision: 1.3 $
Author: aahz at pobox.com (Aahz)
Status: Draft
Type: Informational
Created: 15-Mar-2001
Post-History: 15-Mar-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 patch
    releases of old versions for the primary purpose of fixing bugs.

    This PEP is not, repeat NOT, a guarantee of the existence of patch
    releases; it only specifies a procedure to be followed if patch
    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 bugfixes 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

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


Version Numbers

    Starting with Python 2.0, all feature releases are required to have
    a version number 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.


Procedure

    The process for managing patch releases is modeled in part on the
    Tcl system [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 bugfix suitable for inclusion in a patch release.  If the patch is
    considered suitable, the patch contributor will mail the SourceForge
    patch (bugfix?) 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].

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

    Patch releases are expected to occur at an interval of roughly one
    month.  In general, only the N-1 release will be under active
    maintenance at any time.


Patch Czar History

    Moshe Zadka (moshez at zadka.site.co.il) is the Patch Czar for 2.0.1.


Issues To Be Resolved

    What is the equivalent of python-dev for people who are responsible
    for maintaining Python?  (Aahz proposes either python-patch or
    python-maint, hosted at either python.org or xs4all.net.)

    Does SourceForge make it possible to maintain both separate and
    combined bug lists for multiple forks?  If not, how do we mark bugs
    fixed in different forks?  (Simplest is to simply generate a new bug
    for each fork that it gets fixed in, referring back to the main bug
    number for details.)


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 bugfix 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 bugfix requirement (mainly due to the example of PEP 235 [3],
    which could be argued as either a bugfix 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 bugfixes, but allowing
    multiple patch releases until release N is published.


References

    [1] http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html
    [2] http://python.sourceforge.net/peps/pep-0003.html
    [3] http://python.sourceforge.net/peps/pep-0235.html


Copyright

    This document has been placed in the public domain.


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