[Python-Dev] Re: Stability and change

[Guido van Rossum]

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

Or we could stay longer in beta.

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

I don't think so.  Doctest is extremely picky, on purpose, and a
breaking doctest doesn't mean that regular apps will break.

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

Good point.

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

Well, we can probably ride some of the common fear of X.0 releases.
(Though we'd continuously have to explain that for Python, 2.X
corresponds to X.0 in other vendors' numbering. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)