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

[Thomas Wouters]

On Thu, Mar 15, 2001 at 01:14:54AM -0500, aahz@panix.com wrote:
> [posted to c.l.py.announce and c.l.py; followups to c.l.py; cc'd to
> python-dev]

>     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.

Hmm... Would making 'continue' work inside 'try' count as a bugfix or as a
feature ? It's technically not a syntax change, but practically it is.
(Invalid syntax suddenly becomes valid.) 

>   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.

I'm not for this 'bugfix release', 'patch release' difference. The
numbering/naming convention is too confusing, not clear enough, and I don't
see the added benifit of adding limited features. If people want features,
they should go and get a feature release. The most important bit in patch
('bugfix') releases is not to add more bugs, and rewriting parts of code to
fix a bug is something that is quite likely to insert more bugs. Sure, as
the patch coder, you are probably certain there are no bugs -- but so was
whoever added the bug in the first place :)

>     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.

This process probably needs a firm smack with reality, but that would have
to wait until it meets some, first :) Deciding when to do a bugfix release
is very tricky: some bugs warrant a quick release, but waiting to assemble
more is generally a good idea. The whole beta cycle and windows
installer/RPM/etc process is also a bottleneck. Will Tim do the Windows
Installer (or whoever does it for the regular releases) ? If he's building
the installer anyway, why can't he 'bless' the release right away ?

I'm also not sure if a beta cycle in a bugfix release is really necessary,
especially a month long one. Given that we have a feature release planned
each 6 months, and a feature release has generally 2 alphas and 2 betas,
plus sometimes a release candidate, plus the release itself, and a bugfix
release would have one or two betas too, and say that we do two betas in
those six months, that would make 10+ 'releases' of various form in those 6
months. Ain't no-one[*] going to check them out for a decent spin, they'll
just wait for the final version.

>     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.)

More reasons not to have separate featurebugfixreleasethingies and
bugfix-releases :)

>     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.)

It would probably never be hosted at .xs4all.net. We use the .net address
for network related stuff, and as a nice Personality Enhancer (read: IRC
dick extender) for employees. We'd be happy to host stuff, but I would
actually prefer to have it under a python.org or some other python-related
domainname. That forestalls python questions going to admin@xs4all.net :) A
small logo somewhere on the main page would be nice, but stuff like that
should be discussed if it's ever an option, not just because you like the
name 'XS4ALL' :-)

>     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.)

We could make it a separate SF project, just for the sake of keeping
bugreports/fixes in the maintenance branch and the head branch apart. The
main Python project already has an unwieldy number of open bugreports and
patches.

I'm also for starting the maintenance branch right after the real release,
and start adding bugfixes to it right away, as soon as they show up. Keeping
up to date on bufixes to the head branch is then as 'simple' as watching
python-checkins. (Up until the fact a whole subsystem gets rewritten, that
is :) People should still be able to submit bugfixes for the maintenance
branch specifically.

And I'm still willing to be the patch monkey, though I don't think I'm the
only or the best candidate. I'll happily contribute regardless of who gets
the blame :)

[*] There, that better, Moshe ?
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!