updated bugfix PEP
This commit is contained in:
parent
a860b7fe69
commit
c5f6f6b146
162
pep-0006.txt
162
pep-0006.txt
|
@ -1,11 +1,11 @@
|
||||||
PEP: 6
|
PEP: 6
|
||||||
Title: Bug Fix Releases
|
Title: Bug Fix Releases
|
||||||
Version: $Revision$
|
Version: $Revision$
|
||||||
Author: aahz@pobox.com (Aahz)
|
Author: aahz@pobox.com (Aahz), anthony@interlink.com.au (Anthony Baxter)
|
||||||
Status: Active
|
Status: Active
|
||||||
Type: Informational
|
Type: Informational
|
||||||
Created: 15-Mar-2001
|
Created: 15-Mar-2001
|
||||||
Post-History: 15-Mar-2001 18-Apr-2001
|
Post-History: 15-Mar-2001 18-Apr-2001 19-Aug-2004
|
||||||
|
|
||||||
|
|
||||||
Abstract
|
Abstract
|
||||||
|
@ -13,12 +13,12 @@ Abstract
|
||||||
Python has historically had only a single fork of development,
|
Python has historically had only a single fork of development,
|
||||||
with releases having the combined purpose of adding new features
|
with releases having the combined purpose of adding new features
|
||||||
and delivering bug fixes (these kinds of releases will be referred
|
and delivering bug fixes (these kinds of releases will be referred
|
||||||
to as "feature releases"). This PEP describes how to fork off
|
to as "major releases"). This PEP describes how to fork off
|
||||||
patch releases of old versions for the primary purpose of fixing
|
maintenance, or bug fix, releases of old versions for the primary
|
||||||
bugs.
|
purpose of fixing bugs.
|
||||||
|
|
||||||
This PEP is not, repeat NOT, a guarantee of the existence of patch
|
This PEP is not, repeat NOT, a guarantee of the existence of bug fix
|
||||||
releases; it only specifies a procedure to be followed if patch
|
releases; it only specifies a procedure to be followed if bug fix
|
||||||
releases are desired by enough of the Python community willing to
|
releases are desired by enough of the Python community willing to
|
||||||
do the work.
|
do the work.
|
||||||
|
|
||||||
|
@ -31,8 +31,8 @@ Motivation
|
||||||
upgrading to new versions to get bug fixes when so many features
|
upgrading to new versions to get bug fixes when so many features
|
||||||
have been added, sometimes late in the development cycle.
|
have been added, sometimes late in the development cycle.
|
||||||
|
|
||||||
One solution for this issue is to maintain the previous feature
|
One solution for this issue is to maintain the previous major
|
||||||
release, providing bug fixes until the next feature release. This
|
release, providing bug fixes until the next major release. This
|
||||||
should make Python more attractive for enterprise development,
|
should make Python more attractive for enterprise development,
|
||||||
where Python may need to be installed on hundreds or thousands of
|
where Python may need to be installed on hundreds or thousands of
|
||||||
machines.
|
machines.
|
||||||
|
@ -40,62 +40,116 @@ Motivation
|
||||||
|
|
||||||
Prohibitions
|
Prohibitions
|
||||||
|
|
||||||
Patch releases are required to adhere to the following restrictions:
|
Bug fix releases are required to adhere to the following restrictions:
|
||||||
|
|
||||||
1. There must be zero syntax changes. All .pyc and .pyo files
|
1. There must be zero syntax changes. All .pyc and .pyo files
|
||||||
must work (no regeneration needed) with all patch releases
|
must work (no regeneration needed) with all bugfix releases
|
||||||
forked off from a feature release.
|
forked off from a major release.
|
||||||
|
|
||||||
2. There must be zero pickle changes.
|
2. There must be zero pickle changes.
|
||||||
|
|
||||||
3. There must be no incompatible C API changes. All extensions
|
3. There must be no incompatible C API changes. All extensions
|
||||||
must continue to work without recompiling in all patch releases
|
must continue to work without recompiling in all bugfix releases
|
||||||
in the same fork as a feature release.
|
in the same fork as a major release.
|
||||||
|
|
||||||
Breaking any of these prohibitions requires a BDFL proclamation
|
Breaking any of these prohibitions requires a BDFL proclamation
|
||||||
(and a prominent warning in the release notes).
|
(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 behavior, or worse yet,
|
||||||
|
APIs.
|
||||||
|
|
||||||
|
Applicability of Prohibitions
|
||||||
|
|
||||||
|
The above prohibitions and not-quite-prohibitions apply both
|
||||||
|
for a final release to a bugfix release (for instance, 2.4 to
|
||||||
|
2.4.1) and for one bugfix release to the next in a series
|
||||||
|
(for instance 2.4.1 to 2.4.2).
|
||||||
|
|
||||||
|
Following the prohibitions listed in this PEP should help keep
|
||||||
|
the community happy that a bug fix release is a painless and safe
|
||||||
|
upgrade.
|
||||||
|
|
||||||
|
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, with words like 'Bugfix candidate' or
|
||||||
|
'Backport candidate'.
|
||||||
|
|
||||||
|
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
|
Version Numbers
|
||||||
|
|
||||||
Starting with Python 2.0, all feature releases are required to
|
Starting with Python 2.0, all major releases are required to have
|
||||||
have a version number of the form X.Y; patch releases will always be
|
a version number of the form X.Y; bugfix releases will always be of
|
||||||
of the form X.Y.Z.
|
the form X.Y.Z.
|
||||||
|
|
||||||
The current feature release under development is referred to as
|
The current major release under development is referred to as
|
||||||
release N; the just-released feature version is referred to as
|
release N; the just-released major version is referred to as N-1.
|
||||||
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
|
Procedure
|
||||||
|
|
||||||
The process for managing patch releases is modeled in part on the
|
The process for managing bugfix releases is modeled in part on the Tcl
|
||||||
Tcl system [1].
|
system [1].
|
||||||
|
|
||||||
The Patch Czar is the counterpart to the BDFL for patch releases.
|
The Patch Czar is the counterpart to the BDFL for bugfix releases.
|
||||||
However, the BDFL and designated appointees retain veto power over
|
However, the BDFL and designated appointees retain veto power over
|
||||||
individual patches.
|
individual patches. A Patch Czar might only be looking after a single
|
||||||
|
branch of development - it's quite possible that a different person
|
||||||
|
might be maintaining the 2.3.x and the 2.4.x releases.
|
||||||
|
|
||||||
As individual patches get contributed to the feature release fork,
|
As individual patches get contributed to the current trunk of CVS,
|
||||||
each patch contributor is requested to consider whether the patch is
|
each patch committer is requested to consider whether the patch is
|
||||||
a bug fix suitable for inclusion in a patch release. If the patch is
|
a bug fix suitable for inclusion in a bugfix release. If the patch is
|
||||||
considered suitable, the patch contributor will mail the SourceForge
|
considered suitable, the committer can either commit the release to
|
||||||
patch (bug fix?) number to the maintainers' mailing list.
|
the maintenance branch, or else mark the patch in the commit message.
|
||||||
|
|
||||||
In addition, anyone from the Python community is free to suggest
|
In addition, anyone from the Python community is free to suggest
|
||||||
patches for inclusion. Patches may be submitted specifically for
|
patches for inclusion. Patches may be submitted specifically for
|
||||||
patch releases; they should follow the guidelines in PEP 3 [2].
|
bugfix 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
|
The Patch Czar decides when there are a sufficient number of patches
|
||||||
patches to warrant a release. The release gets packaged up,
|
to warrant a release. The release gets packaged up, including a
|
||||||
including a Windows installer, and made public. If any new bugs
|
Windows installer, and made public. If any new bugs are found, they
|
||||||
are found, they must be fixed immediately and a new patch release
|
must be fixed immediately and a new bugfix release publicized (with
|
||||||
publicized (with an incremented version number).
|
an incremented version number). For the 2.3.x cycle, the Patch Czar
|
||||||
|
(Anthony) has been trying for a release approximately every six
|
||||||
Patch releases are expected to occur at an interval of roughly one
|
months, but this should not be considered binding in any way on
|
||||||
month. In general, only the N-1 release will be under active
|
any future releases.
|
||||||
maintenance at any time.
|
|
||||||
|
|
||||||
|
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. If, however, someone qualified wishes to continue
|
||||||
|
the work to maintain an older release, they should be encouraged.
|
||||||
|
|
||||||
Patch Czar History
|
Patch Czar History
|
||||||
|
|
||||||
|
@ -114,20 +168,6 @@ Patch Czar History
|
||||||
Moshe Zadka is the Patch Czar for 2.0.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
|
History
|
||||||
|
|
||||||
This PEP started life as a proposal on comp.lang.python. The
|
This PEP started life as a proposal on comp.lang.python. The
|
||||||
|
@ -136,21 +176,23 @@ History
|
||||||
also argued for sticking with a strict bug fix policy.
|
also argued for sticking with a strict bug fix policy.
|
||||||
|
|
||||||
Following feedback from the BDFL and others, the draft PEP was
|
Following feedback from the BDFL and others, the draft PEP was
|
||||||
written containing an expanded patch release cycle that permitted
|
written containing an expanded bugfix release cycle that permitted
|
||||||
any previous feature release to obtain patches and also relaxed
|
any previous major release to obtain patches and also relaxed
|
||||||
the strict bug fix requirement (mainly due to the example of PEP
|
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).
|
235 [3], which could be argued as either a bug fix or a feature).
|
||||||
|
|
||||||
Discussion then mostly moved to python-dev, where BDFL finally
|
Discussion then mostly moved to python-dev, where BDFL finally
|
||||||
issued a proclamation basing the Python patch release process on
|
issued a proclamation basing the Python bugfix release process on
|
||||||
Tcl's, which essentially returned to the original proposal in
|
Tcl's, which essentially returned to the original proposal in
|
||||||
terms of being only the N-1 release and only bug fixes, but
|
terms of being only the N-1 release and only bug fixes, but
|
||||||
allowing multiple patch releases until release N is published.
|
allowing multiple bugfix 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
|
References
|
||||||
|
|
||||||
[1] http://dev.scriptics.com:8080/cgi-bin/tct/tip/28.html
|
[1] http://www.tcl.tk/cgi-bin/tct/tip/28.html
|
||||||
|
|
||||||
[2] PEP 3, Guidelines for Handling Bug Reports, Hylton
|
[2] PEP 3, Guidelines for Handling Bug Reports, Hylton
|
||||||
http://www.python.org/peps/pep-0003.html
|
http://www.python.org/peps/pep-0003.html
|
||||||
|
|
Loading…
Reference in New Issue