forked from python/peps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
pep-0006.txt
217 lines (152 loc) · 7.65 KB
/
pep-0006.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
PEP: 6
Title: Bug Fix Releases
Author: Aahz <aahz@pythoncraft.com>, Anthony Baxter <anthony@interlink.com.au>
Status: Active
Type: Process
Content-Type: text/x-rst
Created: 15-Mar-2001
Post-History: 15-Mar-2001, 18-Apr-2001, 19-Aug-2004
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
"major releases"). This PEP describes how to fork off maintenance, or
bug fix, releases of old versions for the primary purpose of fixing
bugs.
This PEP is not, repeat NOT, a guarantee of the existence of bug fix
releases; it only specifies a procedure to be followed if bug fix
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 major release,
providing bug fixes until the next major release. This should make
Python more attractive for enterprise development, where Python may
need to be installed on hundreds or thousands of machines.
Prohibitions
============
Bug fix 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 bugfix releases forked off
from a major 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 bugfix releases in the
same fork as a major release.
Breaking any of these prohibitions requires a BDFL proclamation (and a
prominent warning in the release notes).
Not-Quite-Prohibitions
======================
Where possible, bug fix releases should also:
1. Have no new features. The purpose of a bug fix release is to fix
bugs, not add the latest and greatest whizzo feature from the HEAD
of the CVS root.
2. Be a painless upgrade. Users should feel confident that an upgrade
from 2.x.y to 2.x.(y+1) will not break their running systems. This
means that, unless it is necessary to fix a bug, the standard
library should not change behavior, or worse yet, APIs.
Applicability of Prohibitions
=============================
The above prohibitions and not-quite-prohibitions apply both for a
final release to a bugfix release (for instance, 2.4 to 2.4.1) and for
one bugfix release to the next in a series (for instance 2.4.1 to
2.4.2).
Following the prohibitions listed in this PEP should help keep the
community happy that a bug fix release is a painless and safe upgrade.
Helping the Bug Fix Releases Happen
===================================
Here's a few pointers on helping the bug fix release process along.
1. Backport bug fixes. If you fix a bug, and it seems appropriate,
port it to the CVS branch for the current bug fix release. If
you're unwilling or unable to backport it yourself, make a note in
the commit message, with words like 'Bugfix candidate' or
'Backport candidate'.
2. If you're not sure, ask. Ask the person managing the current bug
fix releases if they think a particular fix is appropriate.
3. If there's a particular bug you'd particularly like fixed in a bug
fix release, jump up and down and try to get it done. Do not wait
until 48 hours before a bug fix release is due, and then start
asking for bug fixes to be included.
Version Numbers
===============
Starting with Python 2.0, all major releases are required to have a
version number of the form X.Y; bugfix releases will always be of the
form X.Y.Z.
The current major release under development is referred to as release
N; the just-released major version is referred to as N-1.
In CVS, the bug fix releases happen on a branch. For release 2.x, the
branch is named 'release2x-maint'. For example, the branch for the 2.3
maintenance releases is release23-maint
Procedure
=========
The process for managing bugfix releases is modeled in part on the Tcl
system [1]_.
The Patch Czar is the counterpart to the BDFL for bugfix releases.
However, the BDFL and designated appointees retain veto power over
individual patches. A Patch Czar might only be looking after a single
branch of development - it's quite possible that a different person
might be maintaining the 2.3.x and the 2.4.x releases.
As individual patches get contributed to the current trunk of CVS,
each patch committer is requested to consider whether the patch is a
bug fix suitable for inclusion in a bugfix release. If the patch is
considered suitable, the committer can either commit the release to
the maintenance branch, or else mark the patch in the commit message.
In addition, anyone from the Python community is free to suggest
patches for inclusion. Patches may be submitted specifically for
bugfix releases; they should follow the guidelines in :pep:`3`. In
general, though, it's probably better that a bug in a specific release
also be fixed on the HEAD as well as the branch.
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 bugfix release publicized (with an
incremented version number). For the 2.3.x cycle, the Patch Czar
(Anthony) has been trying for a release approximately every six
months, but this should not be considered binding in any way on any
future releases.
Bug fix releases are expected to occur at an interval of roughly six
months. This is only a guideline, however - obviously, if a major bug
is found, a bugfix release may be appropriate sooner. In general, only
the N-1 release will be under active maintenance at any time. That is,
during Python 2.4's development, Python 2.3 gets bugfix releases. If,
however, someone qualified wishes to continue the work to maintain an
older release, they should be encouraged.
Patch Czar History
==================
Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4.
Barry Warsaw is the Patch Czar for 2.2.3.
Guido van Rossum is the Patch Czar for 2.2.2.
Michael Hudson is the Patch Czar for 2.2.1.
Anthony Baxter is the Patch Czar for 2.1.2 and 2.1.3.
Thomas Wouters is the Patch Czar for 2.1.1.
Moshe Zadka is the Patch Czar for 2.0.1.
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 bugfix release cycle that permitted any
previous major release to obtain patches and also relaxed the strict
bug fix requirement (mainly due to the example of :pep:`235`, 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 bugfix 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 bugfix
releases until release N is published.
Anthony Baxter then took this PEP and revised it, based on lessons
from the 2.3 release cycle.
References
==========
.. [1] http://www.tcl.tk/cgi-bin/tct/tip/28.html
Copyright
=========
This document has been placed in the public domain.