iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Aahz's latest version, with small formatting changes by Barry.

This commit is contained in:
Barry Warsaw 2001-04-17 16:55:11 +00:00
parent 3c2095478a
commit 3e9538384b
1 changed files with 62 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

130
pep-0006.txt
View File

@ -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