diff --git a/pep-0006.txt b/pep-0006.txt index 5dc437149..d8dcb018e 100644 --- a/pep-0006.txt +++ b/pep-0006.txt @@ -1,5 +1,5 @@ PEP: 6 -Title: Patch and Bug Fix Releases +Title: Bug Fix Releases Version: $Revision$ Author: aahz@pobox.com (Aahz) Status: Draft @@ -31,109 +31,79 @@ Motivation 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 + 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. - 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: + 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 + 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. - -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.) + 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 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. + 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 - XXX This section is still a little light (and probably - controversial!) + 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 and the decision of whether to label a patch - release as a bug fix release. + 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. + 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]. + 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 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. + 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 - 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 @@ -146,9 +116,33 @@ Issues To Be Resolved 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] PEP 3, Hylton, http://python.sourceforge.net/peps/pep-0003.html + [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 Copyright