164 lines
5.7 KiB
Plaintext
164 lines
5.7 KiB
Plaintext
PEP: 6
|
||
Title: Bug Fix Releases
|
||
Version: $Revision$
|
||
Author: aahz@pobox.com (Aahz)
|
||
Status: Active
|
||
Type: Informational
|
||
Created: 15-Mar-2001
|
||
Post-History: 15-Mar-2001 18-Apr-2001
|
||
|
||
|
||
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 "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.
|
||
|
||
|
||
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.
|
||
|
||
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
|
||
|
||
Anthony Baxter (anthony@interlink.com.au) is the Patch Czar for 2.1.2.
|
||
|
||
Thomas Wouters (thomas@xs4all.net) is the Patch Czar for 2.1.1.
|
||
|
||
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
|
||
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
|
||
|
||
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] PEP 3, Guidelines for Handling Bug Reports, Hylton
|
||
http://www.python.org/peps/pep-0003.html
|
||
|
||
[3] PEP 235, Import on Case-Insensitive Platforms, Peters
|
||
http://www.python.org/peps/pep-0235.html
|
||
|
||
|
||
Copyright
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
End:
|