[Python-checkins] CVS: python/nondist/peps pep-0006.txt,NONE,1.1

2001年3月14日 21:33:53 -0800

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv18364
Added Files:
	pep-0006.txt 
Log Message:
PEP 6, Patch and Bug Fix Releases, Aahz
[w/ editorial pass by Barry]
--- NEW FILE: pep-0006.txt ---
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.

Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: