python-peps/pep-0006.txt

172 lines
5.8 KiB
Plaintext
Raw Normal View History

PEP: 6
Title: Bug Fix Releases
Version: $Revision$
Author: aahz@pobox.com (Aahz)
2002-03-11 12:36:50 -05:00
Status: Active
Type: Informational
Created: 15-Mar-2001
2001-06-05 12:39:11 -04:00
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
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 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
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 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.
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 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].
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
2004-05-13 08:00:45 -04:00
Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4.
2001-10-21 14:24:08 -04:00
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.
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 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.
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: