[Python-Dev] Re: Stability and change

Skip Montanaro skip@pobox.com
Mon, 8 Apr 2002 01:45:22 -0500

    BAW> [Barry]
    >> From my own perspective it seems that 2.1.x is viewed as the stable
    >> release family, and each micro release reaffirms its stability.

    GvR> That's about right.  Maybe we should continue to promote
    GvR> 2.1.x and relegate 2.2 to the bleeding edge?  A simple
    GvR> rearrangement of the website might be sufficient.

    BAW> That might not be a bad idea.  2.2's got some neat stuff in it, but
    BAW> until it's well documented, and really beat upon, I don't think we
    BAW> can rightly call it stable.

This sounds more or less like the Linux kernel, except the meaning of the
odd and even minor revisions are reversed.  (Guido: You mentioned before
that you have trouble keeping the Linux stable/experimental kernel numbering
straight.  Just execute "uname -a" and look at the kernel's minor version
number.  I can almost guarantee you aren't running an experimental kernel.
If so, you don't have enough work to do. ;-)

Personally, I think the way it's done in the Linux world is fine and other
than the initial turmoil caused by switching between the current release
scheme and a Linux-like release scheme I think it would probably play well
in Peoria (that is, c.l.py).  You'd dispense with alphas and betas as they
are currently done and use the micro releases for that.  Let's assume
even-numbered minor releases are experimental, and odd-numbered ones are
stable.  The early micro releases of experimental versions would be where
most of the turmoil takes place.  New stuff is added, and maybe ripped back
out if it doesn't work.  As the micro release numbers increase, the amount
of turmoil reduces, the feature set is frozen, and eventually 2.2.N becomes
both 2.3.0 and 2.4.0.  The 2.3.x branch gets essentially nothing but bug
fixes and new development then pours into 2.4.x.

The advantage over the current scheme in my mind is that we have a lot of
turmoil in the release train near to a release.  I think the ideal scenario
would be the exact opposite.  Today, little activity takes place during the
time between one release and the first alpha of the next release.  After
2.x.alpha1 is announced, the repository churns a lot.  The closer and closer
you get to the first beta, the more agitated things seem to become.  I think
this is because you try to set and adhere to specific release dates and
because each release is meant to be "stable".  What's Fred Brooks' aphorism
about software?  "Plan to throw one away."  That can be every other set of
minor releases.

    GvR> Or maybe 2.3 should become 2.2.3.  <0.5 wink>

    BAW> I think the new bool type has already prevented that.

Why?  If you postulate that 2.even.x become the experimental release
branches, then 2.2.3 with a bool type makes perfect sense.  Once the bool
type is in and you're satisfied that you've accounted for most of the
necessary changes, you make a micro release.  No big deal.  Create tgz and
zip files, maybe a Windows installer.  On to the next one.

release-early-release-often-ly, y'rs,