[Python-Dev] Re: Stability and change

[Skip Montanaro]

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

    Anthony> Hm. I'd like to keep the "stable between 2.x.a and 2.x.b" thing
    Anthony> going, if only because the lib/python-x.y directory is shared
    Anthony> between releases.

Anthony,

I don't know if I understand what you're getting at here.  I think that
2.x.a -> 2.x.b should be relatively stable, certainly if x is odd.  Less so
if x is even, but most of the time not dramatically so.

Let's postulate a Linux-like development process (at least w.r.t. CVS
branches) and that the even-numbered minor numbers are the so-called
experimental branches.  Backing up briefly to fantasy land, we'd release
2.0.31, which we decree is "good enough".  It becomes both 2.1.0 and 2.2.0.
We announce a new "stable" release, 2.1.0 and start incorporating bug fixes.
In reality, people will perhaps not start using it until its micro release
number advances a bit, because the broader community will start hitting it
harder and submitting more bug reports and fixes.  Bugs that are fixed in
the 2.1 branch obviously need to migrate across to the 2.2 branch as
necessary.  Enhancements applied to 2.2 would not migrate back to 2.1.  I
don't know if you can get away without a release champion.  As you
indicated, getting behind on backports can be a killer.

In theory, most users and most Linux distributions will ignore the 2.2
branch and stick to 2.1 (those from whom we can pry 1.5.2 out of their cold,
dead fingers).  2.1 releases will occur less frequently, almost entirely
consist of just bug fixes, and should be "stable", which is what I think
you're after.  2.2 releases will occur more frequently and may have a bit
less stability between micro releases (bool type gets added to 2.2.3 and a
bunch if is_* functions get corrected - in 2.2.4 more is_* functions get
corrected, both of which may cause some minor breakage).  People who can't
tolerate a bit of shaky ground won't be messing around with this tree except
to perhaps occasionally try it out.

For this to work, a number of things have to happen.  First, the effort
required to actually cut a release have to drop dramatically.  Even all the
editing of files to replace 2.1.2 with 2.1.3 needs to be automated.  (One
way to accomplish this would be to have a standard patch file whose version
numbers are twiddled, probably by a script, and which is then applied from
the top of the source tree.)  Getting from "let's cut a release tomorrow" to
"2.1.4 is released" should not be much more labor than running "make dist"
and sticking it on SF, at least on the Unix side of things.  I don't know
what's involved in making a Windows installer, but somebody besides Tim
should be able to do that too.  I presume that over time, the Mac will look
more and more like Unix for distribution purposes as fewer and fewer people
use Mac OS <= 9.

Skip