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

Guido van Rossum guido@python.org
Sat, 06 Apr 2002 20:52:55 -0500

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/)