[Python-checkins] python/nondist/peps pep-0006.txt,1.10,1.11
anthonybaxter at users.sourceforge.net
anthonybaxter at users.sourceforge.net
Thu Aug 19 09:06:15 CEST 2004
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5799
Modified Files:
pep-0006.txt
Log Message:
updated bugfix PEP
Index: pep-0006.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0006.txt,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** pep-0006.txt 13 May 2004 12:00:45 -0000 1.10
--- pep-0006.txt 19 Aug 2004 07:06:12 -0000 1.11
***************
*** 2,10 ****
Title: Bug Fix Releases
Version: $Revision$
! Author: aahz at pobox.com (Aahz)
Status: Active
Type: Informational
Created: 15-Mar-2001
! Post-History: 15-Mar-2001 18-Apr-2001
--- 2,10 ----
Title: Bug Fix Releases
Version: $Revision$
! 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 19-Aug-2004
***************
*** 14,23 ****
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.
--- 14,23 ----
with releases having the combined purpose of adding new features
and delivering bug fixes (these kinds of releases will be referred
! to as "major 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.
***************
*** 32,37 ****
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
--- 32,37 ----
have been added, sometimes late in the development cycle.
! One solution for this issue is to maintain the previous major
! release, providing bug fixes until the next major release. This
should make Python more attractive for enterprise development,
where Python may need to be installed on hundreds or thousands of
***************
*** 41,100 ****
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
--- 41,154 ----
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 bugfix releases
! forked off from a major 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 bugfix releases
! in the same fork as a major 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 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
! Starting with Python 2.0, all major releases are required to have
! a version number of the form X.Y; bugfix releases will always be of
! the form X.Y.Z.
! The current major release under development is referred to as
! release N; the just-released major 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 bugfix releases is modeled in part on the Tcl
! system [1].
! The Patch Czar is the counterpart to the BDFL for bugfix releases.
However, the BDFL and designated appointees retain veto power over
! 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 current trunk of CVS,
! each patch committer is requested to consider whether the patch is
! a bug fix suitable for inclusion in a bugfix release. If the patch is
! considered suitable, the committer can either commit the release to
! the maintenance branch, or else mark the patch in the commit message.
In addition, anyone from the Python community is free to suggest
! patches for inclusion. Patches may be submitted specifically for
! 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 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 bugfix release publicized (with
! an incremented version number). For the 2.3.x cycle, the Patch Czar
! (Anthony) has been trying for a release approximately every six
! months, but this should not be considered binding in any way on
! any future releases.
+ 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
***************
*** 115,132 ****
- 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
--- 169,172 ----
***************
*** 137,155 ****
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
--- 177,197 ----
Following feedback from the BDFL and others, the draft PEP was
! written containing an expanded bugfix release cycle that permitted
! any previous major 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 bugfix 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 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
! [1] http://www.tcl.tk/cgi-bin/tct/tip/28.html
[2] PEP 3, Guidelines for Handling Bug Reports, Hylton
More information about the Python-checkins
mailing list