PEP 6: Patch and Bug Fix Releases

[Aahz Maruch]

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

Okay, folks, here it is, the first draft of the spec for creating Python
maintenance releases.  Note that I'm not on python-dev, so it's probably
better to have the discussion on c.l.py if possible.

            PEP: 6
          Title: Patch and Bug Fix Releases
        Version: $Revision: 1.1 $
         Author: aahz at pobox.com (Aahz)
         Status: Draft
           Type: Informational
        Created: 15-Mar-2001
   Post-History:
     _________________________________________________________________
   
  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 old feature releases,
    providing bug fixes and (minimal!) feature additions.  This will
    make Python more attractive for enterprise development, where
    Python may need to be installed on hundreds or thousands of
    machines.

    At the same time, many of the core Python developers are
    understandably reluctant to devote a significant fraction of their
    time and energy to what they perceive as grunt work.  On the
    gripping hand, people are likely to feel discomfort around
    installing releases that are not certified by PythonLabs.


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


  Bug Fix Releases
  
    Bug fix releases are a subset of all patch releases; it is
    prohibited to add any features to the core in a bug fix release.
    A patch release that is not a bug fix release may contain minor
    feature enhancements, subject to the Prohibitions section.

    The standard for patches to extensions and modules is a bit more
    lenient, to account for the possible desirability of including a
    module from a future version that contains mostly bug fixes but
    may also have some small feature changes.  (E.g. Fredrik Lundh
    making available the 2.1 sre module for 2.0 and 1.5.2.)


  Version Numbers
  
    Starting with Python 2.0, all feature releases are required to
    have the form X.Y; patch releases will always be of the form
    X.Y.Z.  To clarify the distinction between a bug fix release and a
    patch release, all non-bug fix patch releases will have the suffix
    "p" added.  For example, "2.1" is a feature release; "2.1.1" is a
    bug fix release; and "2.1.2p" is a patch release that contains
    minor feature enhancements.


  Procedure
  
    XXX This section is still a little light (and probably
    controversial!)

    The Patch Czar is the counterpart to the BDFL for patch releases.
    However, the BDFL and designated appointees retain veto power over
    individual patches and the decision of whether to label a patch
    release as a bug fix release.

    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[1].

    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 as a beta release.
    If any new bugs are found, they must be fixed and a new beta
    release publicized.  Once a beta cycle completes with no new bugs
    found, the package is sent to PythonLabs for certification and
    publication on python.org.

    Each beta cycle must last a minimum of one month.


  Issues To Be Resolved
  
    Should the first patch release following any feature release be
    required to be a bug fix release?  (Aahz proposes "yes".)

    Is it allowed to do multiple forks (e.g. is it permitted to have
    both 2.0.2 and 2.0.2p)?  (Aahz proposes "no".)

    Does it makes sense for a bug fix release to follow a patch
    release?  (E.g., 2.0.1, 2.0.2p, 2.0.3.)

    Exactly how does a candidate patch release get submitted to
    PythonLabs for certification?  And what does "certification" mean,
    anyway?  ;-)

    Who is the Patch Czar?  Is the Patch Czar a single person?  (Aahz
    says "not me alone".  Aahz is willing to do a lot of the
    non-technical work, but Aahz is not a C programmer.)

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


  References
  
    [1] PEP 3, Hylton, http://python.sourceforge.net/peps/pep-0003.html


  Copyright
  
    This document has been placed in the public domain.