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

Thomas Wouters thomas@xs4all.net
Sun, 18 Mar 2001 00:01:09 +0100


On Sat, Mar 17, 2001 at 08:35:17AM -0800, aahz@panix.com wrote:

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

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

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

Keeping too many maintenance branches active does bring the administrative
nightmare with it, of course. We can start with just N-1 and see where it
goes from there. If significant numbers of people are still using 2.0.5 when
2.2 comes out, we might have to reconsider.

-- 
Thomas Wouters <thomas@xs4all.net>

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