PEP 6, Patch and Bug Fix Releases, Aahz
[w/ editorial pass by Barry]
This commit is contained in:
Barry Warsaw
parent
f24ebbe019
commit
6e33012633
|
|
@ -0,0 +1,163 @@
|
|||
PEP: 6
|
||||
Title: Patch and Bug Fix Releases
|
||||
Version: $Revision$
|
||||
Author: aahz@pobox.com (Aahz)
|
||||
Status: Draft
|
||||
Type: Informational
|
||||
Created: 15-Mar-2001
|
||||
Post-History:
|
||||
|
||||
|
||||
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 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
|
||||
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:
|
||||
|
||||
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
|
||||
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.)
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Procedure
|
||||
|
||||
XXX This section is still a little light (and probably
|
||||
controversial!)
|
||||
|
||||
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.
|
||||
|
||||
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[1].
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
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.)
|
||||
|
||||
|
||||
References
|
||||
|
||||
[1] PEP 3, Hylton, http://python.sourceforge.net/peps/pep-0003.html
|
||||
|
||||
|
||||
Copyright
|
||||
|
||||
This document has been placed in the public domain.
|
||||
|
||||
|
||||
|
||||
Local Variables:
|
||||
mode: indented-text
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
Loading…
Reference in New Issue