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

[Guido van Rossum]

> >> Remember that all bugfixes are available as patches off of SourceForge.
> > 
> > I'm sorry, Aahz, but that is just plain not true. It's not a little bit not
> > true, it's very not true. A lot of the patches applied are either never
> > submitted to SF (because it's the 'obvious fix' by one of the commiters) or
> > are modified to some extent from thh SF patch proposed. (Often
> > formatting/code style, fairly frequently symbol renaming, and not too
> > infrequently changes in the logic for various reasons.)
> 
> I'm thinking one of us is confused.  CVS is hosted at SourceForge,
> right?  People can download specific parts of Python from SF?  And we're
> presuming there will be a specific fork that patches are checked in to?
> So in what way is my statement not true?

Ah...  Thomas clearly thought you meant the patch manager, and you
didn't make it too clear that's not what you meant.  Yes, they are of
course all available as diffs -- and notice how I use this fact in the
2.0 patches lists in the 2.0 wiki, e.g. on
http://www.python.org/cgi-bin/moinmoin/CriticalPatches.

> >>> ... 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.
> >> 
> >> That's why I'm making the beta cycle artificially long (I'd even vote
> >> for a two-month minimum).  It slows the release pace and -- given the
> >> usually high quality of Python betas -- it encourages people to try them
> >> out.  I believe that we *do* need patch betas for system testing.
> > 
> > But having a patch release once every 6 months negates the whole
> > purpose of patch releases :) If you are in need of a bugfix, you
> > don't want to wait three months before a bugfix release beta with
> > your specific bug fixed is going to be released, and you don't want
> > to wait two months more for the release to become final. (Note: we're
> > talking people who don't want to use the next feature release beta or
> > current CVS version, so they aren't likely to try a bugfix release
> > beta either.) Bugfix releases should come often-ish, compared to
> > feature releases. But maybe we can get the BDFL to slow the pace of
> > feature releases instead ? Is the 6-month speedway really appropriate
> > if we have a separate bugfix release track ?
> 
> Well, given that neither of us is arguing on the basis of actual
> experience with Python patch releases, there's no way we can prove one
> point of view as being better than the other.  Tell you what, though:
> take the job of Patch Czar, and I'll follow your lead.  I'll just
> reserve the right to say "I told you so".  ;-)

It seems I need to butt in here.  :-)

I like the model used by Tcl.  They have releases with a 6-12 month
release cycle, 8.0, 8.1, 8.2, 8.3, 8.4.  These have serious alpha and
beta cycles (three of each typically).  Once a release is out, the
issue occasional patch releases, e.g. 8.2.1, 8.2.2, 8.2.3; these are
about a month apart.  The latter bugfixes overlap with the early alpha
releases of the next major release.  I see no sign of beta cycles for
the patch releases.  The patch releases are *very* conservative in
what they add -- just bugfixes, about 5-15 per bugfix release.  They
seem to add the bugfixes to the patch branch as soon as they get them,
and they issue patch releases as soon as they can.

I like this model a lot.  Aahz, if you want to, you can consider this
a BDFL proclamation -- can you add this to your PEP?

> >>> 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.
> > 
> >> That is *precisely* why my original proposal suggested that only
> >> the N-1 release get patch attention, to conserve effort.  It is
> >> also why I suggested that patch releases get hooked to feature
> >> releases.
> > 
> > There is no technical reason to do just N-1. You can branch of as
> > often as you want (in fact, branches never disappear, so if we
> > were building 3.5 ten years from now (and we would still be using
> > CVS <wink GregS>) we could apply a specific patch to the 2.0
> > maintenance branch and release 2.0.128, if need be.)
> 
> No technical reason, no.  It's just that N-1 is going to be similar
> enough to N, particularly for any given bugfix, that it should be
> "trivial" to keep the bugfixes in synch.  That's all.

I agree.  The Tcl folks never issue patch releases when they've issued
a new major release (in fact the patch releases seem to stop long
before they're ready to issue the next major release).  I realize that
we're way behind with 2.0.1 -- since this is the first time we're
doing this, that's OK for now, but in the future I like the Tcl
approach a lot!

--Guido van Rossum (home page: http://www.python.org/~guido/)