[Python-Dev] PEP 6: Patch and Bug Fix Releases
aahz@panix.com
aahz@panix.com
Thu, 15 Mar 2001 01:14:54 -0500 (EST)
[posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to
python-dev]
Okay, folks, here it is, the first draft of the spec for creating Python
maintenance releases. Note that I'm not on python-dev, so it's probably
better to have the discussion on c.l.py if possible.
PEP: 6
Title: Patch and Bug Fix Releases
Version: $Revision: 1.1 $
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.
--
--- Aahz <*> (Copyright 2001 by aahz@pobox.com)
Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6
"The overexamined life sure is boring." --Loyal Mini Onion