[Python-Dev] Re: Stability and change

[Alex Martelli]

On Saturday 06 April 2002 05:48 pm, Guido van Rossum wrote:
> On c.p.py, Alex Martelli wrote:
> > Linus Thorvalds seems to have done pretty well with picking TWO
> > middle grounds -- two parallel tracks for Linux, "stable" and
> > "experimental".
>
> I'm moving the discussion to python-dev, since that's where I think it
> belongs.

Right.

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

Sounds quite workable, as long as we never want to do "bug-fix" point
releases for experimental/bleeding-edge versions.  The Linux folks do
several experimental A.B (with B being odd, meaning experimental).N,
but then Linux kernel/modules/drivers ARE an order of magnitude
larger than Python, so we may not have analogous needs -- I dunno.


> This would require only a very slight change of policy: PEP 6 would
> have to be renamed from "Bug Fix Releases" to "Stable Releases".  It
> wouldn't even have to loosen up its prohibitions; quoting:
	...
> This doesn't prevent us to evolve the standard library.  It doesn't
> prohibit adding new built-in functions, although I'd be reluctant to
> do so.

Yes, library changes should be OK, as long as they don't alter behavior 
of code which used to run (without specific BDFL proclamation and 
prominent notice).  I personally wouldn't mind if some good-intention
wording about not breaking existing doctests (e.g. no change in wording
of error messages) snuck in, but then I'm a doctest junky.


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

Yes, public perception issues are to some extent paramount to
ensure this slight variation has the intended effect.

Your freedom to experiment as well as public perception might be
enhanced by some explicit mention that the first (.1) stable release 
does not guarantee 100% compatibility with the immediately
previous bleeding-edge/experimental release, so you can (within
some common-sense bounds) try putting something in 2.X and
then taking it away in 2.X.1 if it didn't work.  I.e., stability being
guaranteed 2.X.1 -> 2.X.2 and so on, but not necessarily 2.X -> 2.X.1,
just as not necessarily 2.(X-1).N -> 2..X.1.

Other folks more adept at marketing than me may come up with
other ways to help public perception of 2.X.Y as "good, solid,
stable, NOT old, dusty, junky" and thus helping this variant on
"dual-track" fulfil its role.


Alex