[Python-checkins] CVS: python/nondist/peps pep-0006.txt,1.2,1.3
Barry Warsaw
bwarsaw@users.sourceforge.net
Tue, 17 Apr 2001 09:55:13 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv29925
Modified Files:
pep-0006.txt
Log Message:
Aahz's latest version, with small formatting changes by Barry.
Index: pep-0006.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0006.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -r1.2 -r1.3
*** pep-0006.txt 2001/03/15 14:11:16 1.2
--- pep-0006.txt 2001/04/17 16:55:11 1.3
***************
*** 1,4 ****
PEP: 6
! Title: Patch and Bug Fix Releases
Version: $Revision$
Author: aahz@pobox.com (Aahz)
--- 1,4 ----
PEP: 6
! Title: Bug Fix Releases
Version: $Revision$
Author: aahz@pobox.com (Aahz)
***************
*** 32,137 ****
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
--- 32,107 ----
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 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
! Moshe Zadka (moshez@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
***************
*** 147,153 ****
References
! [1] PEP 3, Hylton, http://python.sourceforge.net/peps/pep-0003.html
--- 117,147 ----
+ 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] http://python.sourceforge.net/peps/pep-0003.html
! [3] http://python.sourceforge.net/peps/pep-0235.html