[Python-Dev] Re: Stability and change

[Aahz]

On Sat, Apr 06, 2002, Guido van Rossum wrote:
>
> Personally, I hate the way Linux releases are numbered (I can never
> tell which one is stable and which one isn't).  But I could get used
> to it if we used the micro version number to indicate stability -- in
> particular, 2.2 would be experimental, and 2.2.1 and following would
> be stable; 2.3 would be experimental, and 2.3.1 stable.

I'm kind of in agreement with Tim; I don't think this buys much.  Seems
more important to me to specify process than stability per se.

> It would, however, require a big change in how we present new releases
> to the world.  Currently, Once 2.x is out, anything running 2.(x-1) is
> labeled obsolete, or at least oldfashioned.  That needs to change!
> The website needs to present at least two options:
> 
> - Bleeding edge (e.g. 2.3 alpha, or 2.3 once it's out)
> 
> - Stable (e.g. 2.2.1)
> 
> There may be more options: Zope 2 currently requires 2.1.2 and will
> require 2.1.3 as soon as it's out; other people still swear by 1.5.2.
> (I don't think that the 1.6 and 2.0 lines are still popular.)

What I suggest is that instead of

    major.minor.bugfix

we do

    major.minor.enhanced.bugfix

This way, only major.minor releases can introduce actual language
changes, but enhancement releases can pick up library changes.  If this
sounds at all workable, I recommend issuing a quick BDFL pronouncement
changing 2.2.1 to 2.2.0.1.

Then what we might try for a 2.2.1 release is making the new boolean
type a module that people can start using.


I am also a bit amused because an early draft of PEP 6 did try to
address this issue, but you and Tim dissuaded me.  I think both of you
were right back then, but it's still kind of funny to see it picked up a
year later.
-- 
Aahz (aahz@pythoncraft.com)           <*>         http://www.pythoncraft.com/

"There are times when effort is important and necessary, but this should
not be taken as any kind of moral imperative."  --jdecker