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

Anthony Baxter Anthony Baxter anthony@interlink.com.au
Tue, 09 Apr 2002 00:34:11 +1000

Skip Montanaro wrote 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.

On thinking about it some more, I don't think I like the "even == experimental, odd == stable" approach. It's way too mystical and non- obvious. All too much magic, and particularly if we say that "2.odd.n -> 2.odd.n+1 is guaranteed to be stable, but 2.even.n -> 2.even.n+1, all bets are off". I'm not sure I can think of a better approach, unfortunately, unless we do something like "the release 2.n will be supported for at least {X minor revisions of 2.n+1, X months after 2.n+1.0, ....}", and have something like that. So 2.1.x is "stable" until after 2.2.1 is out and happy. In practice, this is what happens anyway - I know I'm not running anything I really care about on 2.2 yet.

I'm also not so keen on the version-itis that I think having multiple active branches will lead to. I look at Perl and I go "ick". It seems every time I want to install a perl package, I have to go through a painful exercise in upgrading half the damn cpan-installed packages on my system - and every time I've tried to use the 'auto-follow dependencies', I've come back to find it's downloaded the latest and greatest point release of the perl core and is building it, because some package requires the most bleeding edge features. I don't want to have to play that game in python.

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.

The editing of files is completely and utterly the least of the problems. It's mostly a matter of pushing the right buttons on the right web interfaces, that sort of thing. Now while this could be automated, there's not a lot of point. Since 2.1.2, the sourceforge interfaces for doing a file release have changed, slightly. Not so much that a human can't figure it out, but it'd stuff any automated systems completely.

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 wish! Have a read of PEP 102.

I don't know what's involved in making a Windows installer, but somebody besides Tim should be able to do that too.

I assume nothing.

-- Anthony Baxter <anthony@interlink.com.au>
It's never too late to have a happy childhood.