[Python-Dev] PEP 6: Patch and Bug Fix Releases

Aahz Maruch aahz@pobox.com
Thu, 15 Mar 2001 14:34:26 -0800 (PST)


>     aahz> Starting with Python 2.0, all feature releases are required to
>     aahz> have the form X.Y; patch releases will always be of the form
>     aahz> X.Y.Z.  To clarify the distinction between a bug fix release and a
>     aahz> patch release, all non-bug fix patch releases will have the suffix
>     aahz> "p" added.  For example, "2.1" is a feature release; "2.1.1" is a
>     aahz> bug fix release; and "2.1.2p" is a patch release that contains
>     aahz> minor feature enhancements.
> 
> I don't understand the need for (or fundamental difference between) bug fix
> and patch releases.  If 2.1 is the feature release and 2.1.1 is a bug fix
> release, is 2.1.2p a branch off of 2.1.2 or 2.1.1?

That's one of the issues that needs to be resolved if we permit both
patch releases and bug fix releases.  My preference would be that 2.1.2p
is a branch from 2.1.1.

>     aahz> The Patch Czar is the counterpart to the BDFL for patch releases.
>     aahz> However, the BDFL and designated appointees retain veto power over
>     aahz> individual patches and the decision of whether to label a patch
>     aahz> release as a bug fix release.
> 
> I propose that instead of (or in addition to) the Patch Czar you have a
> Release Shepherd (RS) for each feature release, presumably someone motivated
> to help maintain that particular release.  This person (almost certainly
> someone outside PythonLabs) would be responsible for the bug fix releases
> associated with a single feature release.  Your use of 2.1's sre as a "small
> feature change" for 2.0 and 1.5.2 is an example where having an RS for each
> feature release would be worthwhile.  Applying sre 2.1 to the 2.0 source
> would probably be reasonably easy.  Adding it to 1.5.2 would be much more
> difficult (no Unicode), and so would quite possibly be accepted by the 2.0
> RS and rejected by the 1.5.2 RS.

That may be a good idea.  Comments from others?  (Note that in the case
of sre, I was aware that Fredrik had already backported to both 2.0 and
1.5.2.)

> I suggest dumping the patch release concept and just going with bug fix
> releases.  The system will be complex enough without them.  If it proves
> desirable later, you can always add them.

Well, that was my original proposal before turning this into an official
PEP.  The stumbling block was the example of the case-sensitive import
patch (that permits Python's use on BeOS and MacOS X) for 2.1.  Both
Guido and Tim stated their belief that this was a "feature" and not a
"bug fix" (and I don't really disagree with them).  This leaves the
following options (assuming that backporting the import fix doesn't break
one of the Prohibitions):

* Change the minds of Guido/Tim to make the import issue a bugfix.

* Don't backport case-sensitive imports to 2.0.

* Permit minor feature additions/changes.

If we choose that last option, I believe a distinction should be drawn
between releases that contain only bugfixes and releases that contain a
bit more.
-- 
                      --- 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

Three sins: BJ, B&J, B&J