[Python-Dev] Re: Stability and change

[Guido van Rossum]

I just thought of another issue.  James Logajan (possibly our most
outspoken conservative developer) brought up the problem that whenever
you install a new version, you start developing for that version, and
your code is no longer portable to previous versions.  Even if we had
a perfect track record of keeping old code working, the addition of
new, enticing features has a "lock-in" effect.  (We may sometimes have
done this on purpose, at least semi-consciously.)

This would suggest designating each series 2.X, 2.X.1, 2.X.2, 2.X.3,
... as an asymptotic series approaching perfection for a given feature
set, where the feature set is pretty much frozen the moment 2.X is
released.  Then user code portability within the 2.X series is close
to guaranteed, making it easy to move a script to a previous version,
and if that doesn't work because the script relies on some bug being
fixed, there shouldn't be much resistance to upgrading 2.X.Y to
2.X.(Y+1).  We have to commit to maintaining a 2.X series as long as
it is in use.

I don't think I want to chop off the leading "2." -- since as we're
releasing new versions every 6-12 months, this would move us to 9.0
way too quickly.  It shouldn't be too hard for users to get used to
the fact that the jump from 2.X to 2.(X+1) is usually a big one
(despite comments that the jump from 2.1 to 2.2 was as big as the one
from 1.5.2 to 2.0 -- after all, so was the jump from 1.5.1 to
1.5.2, so we're already doing better. :-)

I'm not sure what exactly we need to *do* now.  Be clearer to the user
community that we're still maintaining 2.1.*?  Delay the 2.3 release
and spend more time on 2.2.2 (assuming that 2.2.1 is about to go out)?
Change the Makefile and the RPMs to install each 2.X version under a
different name, e.g. only install as python2.2?[*]  Rearrange the
website to emphasize the stable version?

While I agree that 2.1.x is the most stable release, there's also a
significant user population who want to use 2.2 (e.g. the new Boost
library wrappers use new-style classes).  We should maintain the 2.2.x
line for their benefit.  And then maybe we could take our time
releasing 2.3 while experimenting with new features to our heart's
content.  To counteract the fact (as Tim noted) that few users bother
to download betas, maybe we could release 2.3 relatively rough,
clearly mark it as an experimental release, and work on improvements
and stability in 2.3.1, 2.3.2 and so on, until we're happy to call it
stable and start experimenting with 2.4.  While we're working the
kinks out of 2.3.x, the most stable release advertised would be 2.1.x,
and adventurous users could basically choose between 2.2.x (advanced
but stable) or 2.3.x (bleeding edge).

Compared to the Linux numbering scheme, we'd lose the "mnemonic" value
(if you can call it that) of even-stable / odd-experimental; instead,
we'd have to give each release a color, maybe starting with red
(bleeding edge) going via yellow (advanced but stable) to green (most
stable), and finally to blue (behind the pack) and black (dead).

-----

[*] Here's an idea.  Maybe "make install" should check if there's
already a $(prefix)/bin/python that's got a different major.minor
version number than the one it's about to install, and then *ask*
whether to make a link named "python" to the new version rather than
just doing it (unless you specified "make altinstall", which probably
too few people know about).

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