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

Skip Montanaro skip@pobox.com
Mon, 8 Apr 2002 09:04:35 -0500 

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