Note
This PEP is obsolete.The current release policy is documented inthe devguide.See alsoPEP 101 for mechanics of the release process.
Python has historically had only a single fork of development, withreleases having the combined purpose of adding new features anddelivering bug fixes (these kinds of releases will be referred to as“major releases”). This PEP describes how to fork off maintenance, orbug fix, releases of old versions for the primary purpose of fixingbugs.
This PEP is not, repeat NOT, a guarantee of the existence of bug fixreleases; it only specifies a procedure to be followed if bug fixreleases are desired by enough of the Python community willing to dothe work.
With the move to SourceForge, Python development has accelerated.There is a sentiment among part of the community that there was toomuch acceleration, and many people are uncomfortable with upgrading tonew 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 makePython more attractive for enterprise development, where Python mayneed to be installed on hundreds or thousands of machines.
Bug fix releases are required to adhere to the following restrictions:
.pyc and.pyo files mustwork (no regeneration needed) with all bugfix releases forked offfrom a major release.Breaking any of these prohibitions requires a BDFL proclamation (and aprominent warning in the release notes).
Where possible, bug fix releases should also:
The above prohibitions and not-quite-prohibitions apply both for afinal release to a bugfix release (for instance, 2.4 to 2.4.1) and forone bugfix release to the next in a series (for instance 2.4.1 to2.4.2).
Following the prohibitions listed in this PEP should help keep thecommunity happy that a bug fix release is a painless and safe upgrade.
Here’s a few pointers on helping the bug fix release process along.
Starting with Python 2.0, all major releases are required to have aversion number of the form X.Y; bugfix releases will always be of theform X.Y.Z.
The current major release under development is referred to as releaseN; 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, thebranch is named ‘release2x-maint’. For example, the branch for the 2.3maintenance releases is release23-maint
The process for managing bugfix releases is modeled in part on the Tclsystem[1].
The Patch Czar is the counterpart to the BDFL for bugfix releases.However, the BDFL and designated appointees retain veto power overindividual patches. A Patch Czar might only be looking after a singlebranch of development - it’s quite possible that a different personmight 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 abug fix suitable for inclusion in a bugfix release. If the patch isconsidered suitable, the committer can either commit the release tothe maintenance branch, or else mark the patch in the commit message.
In addition, anyone from the Python community is free to suggestpatches for inclusion. Patches may be submitted specifically forbugfix releases; they should follow the guidelines inPEP 3. Ingeneral, though, it’s probably better that a bug in a specific releasealso be fixed on the HEAD as well as the branch.
The Patch Czar decides when there are a sufficient number of patchesto warrant a release. The release gets packaged up, including aWindows installer, and made public. If any new bugs are found, theymust be fixed immediately and a new bugfix release publicized (with anincremented version number). For the 2.3.x cycle, the Patch Czar(Anthony) has been trying for a release approximately every sixmonths, but this should not be considered binding in any way on anyfuture releases.
Bug fix releases are expected to occur at an interval of roughly sixmonths. This is only a guideline, however - obviously, if a major bugis found, a bugfix release may be appropriate sooner. In general, onlythe 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 anolder release, they should be encouraged.
Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4.
Barry Warsaw is the Patch Czar for 2.2.3.
Guido van Rossum is the Patch Czar for 2.2.2.
Michael Hudson is the Patch Czar for 2.2.1.
Anthony Baxter is the Patch Czar for 2.1.2 and 2.1.3.
Thomas Wouters is the Patch Czar for 2.1.1.
Moshe Zadka is the Patch Czar for 2.0.1.
This PEP started life as a proposal on comp.lang.python. The originalversion suggested a single patch for the N-1 release to be releasedconcurrently with the N release. The original version also argued forsticking with a strict bug fix policy.
Following feedback from the BDFL and others, the draft PEP was writtencontaining an expanded bugfix release cycle that permitted anyprevious major release to obtain patches and also relaxed the strictbug fix requirement (mainly due to the example ofPEP 235, whichcould be argued as either a bug fix or a feature).
Discussion then mostly moved to python-dev, where BDFL finally issueda proclamation basing the Python bugfix release process on Tcl’s,which essentially returned to the original proposal in terms of beingonly the N-1 release and only bug fixes, but allowing multiple bugfixreleases until release N is published.
Anthony Baxter then took this PEP and revised it, based on lessonsfrom the 2.3 release cycle.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0006.rst
Last modified:2025-02-01 08:55:40 GMT