From cae235ae454511ea6dd830e17f60fe0b07c6daa9 Mon Sep 17 00:00:00 2001 From: Matthias Bussonnier Date: Sun, 19 Jun 2016 15:42:07 -0700 Subject: [PATCH] Convert PEP 6 to reST format (#22) --- pep-0006.txt | 276 +++++++++++++++++++++++++++------------------------ 1 file changed, 144 insertions(+), 132 deletions(-) diff --git a/pep-0006.txt b/pep-0006.txt index 2df5d0d8d..93cb72d84 100644 --- a/pep-0006.txt +++ b/pep-0006.txt @@ -5,217 +5,229 @@ Last-Modified: $Date$ Author: aahz@pythoncraft.com (Aahz), anthony@interlink.com.au (Anthony Baxter) Status: Active Type: Process +Content-Type: text/x-rst Created: 15-Mar-2001 Post-History: 15-Mar-2001 18-Apr-2001 19-Aug-2004 + 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 "major releases"). This PEP describes how to fork off - maintenance, or bug fix, releases of old versions for the primary - purpose of fixing bugs. +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 +"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. +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. 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. +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 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 - machines. +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 machines. Prohibitions +============ - Bug fix 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 - must work (no regeneration needed) with all bugfix releases - forked off from a major release. +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. +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. +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). +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: +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. +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. +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). +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. +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. +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'. +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. +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. +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. +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. +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 +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 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. +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. +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. +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. +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. +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 +================== - Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4. +Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4. - Barry Warsaw is the Patch Czar for 2.2.3. +Barry Warsaw is the Patch Czar for 2.2.3. - Guido van Rossum is the Patch Czar for 2.2.2. +Guido van Rossum is the Patch Czar for 2.2.2. - Michael Hudson is the Patch Czar for 2.2.1. +Michael Hudson is the Patch Czar for 2.2.1. - Anthony Baxter is the Patch Czar for 2.1.2 and 2.1.3. +Anthony Baxter is the Patch Czar for 2.1.2 and 2.1.3. - Thomas Wouters is the Patch Czar for 2.1.1. +Thomas Wouters is the Patch Czar for 2.1.1. - Moshe Zadka is the Patch Czar for 2.0.1. +Moshe Zadka is the Patch Czar for 2.0.1. 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. +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 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). +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. +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. +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 +.. [1] http://www.tcl.tk/cgi-bin/tct/tip/28.html - [2] PEP 3, Guidelines for Handling Bug Reports, Hylton - http://www.python.org/dev/peps/pep-0003/ - [3] PEP 235, Import on Case-Insensitive Platforms, Peters - http://www.python.org/dev/peps/pep-0235/ +.. [2] PEP 3, Guidelines for Handling Bug Reports, Hylton + (http://www.python.org/dev/peps/pep-0003/) + +.. [3] PEP 235, Import on Case-Insensitive Platforms, Peters + (http://www.python.org/dev/peps/pep-0235/) Copyright +========= - This document has been placed in the public domain. +This document has been placed in the public domain. - -Local Variables: -mode: indented-text -indent-tabs-mode: nil -End: +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + End: