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

Alex Martelli aleax@aleax.it
Sat, 6 Apr 2002 18:06:21 +0200

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