[Python-Dev] Re: Stability and change

[Anthony Baxter]

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