[Python-Dev] Re: Stability and change (original) (raw)

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,

Skip