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

Tim Peters tim.one@comcast.net
Sun, 07 Apr 2002 00:16:05 -0500

[Guido]

I just thought of another issue. James Logajan (possibly our most outspoken conservative developer)

Ex-developer: he's made it quite clear that he no longer intends to use Python at all (after some brief current period of "compatibilizing" his old code).

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.

I must be exceptional -- this wasn't news to me .

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

I've done it with full awareness in my own code.

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.

If this differs from what we're doing today, I don't understand how: "no incompatibilities and new no features!" has been strongly observed in the bugfix releases.

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.

Again this appears to be arguing for what we already do. Maybe with one difference: I assure people on c.l.py that PLabs will continue distributing I.J.K for increasing K for as long as the community contributes the work for bugfix releases. Perhaps you're saying that PLabs should take that over?

Note too that it wouldn't make James Logajan one whit happier, if we're to take him at his word. He developed some scripts for 1.5.2, and that's it. He wants them to work forever under all future Python releases and all platforms, and got particularly burned by Unicode's interaction with how Tk deals with UTF-8 (and a lot of people got burned by that).

... I'm not sure what exactly we need to do now. Be clearer to the user community that we're still maintaining 2.1.*?

Are we? We've made no effort to backport any bugfixes into 2.1.3, and to the contrary declared that we wouldn't do anything with 2.1.3 except fix the single gc-vs-trashcan disaster. We're not even building a Windows installer for 2.1.3 (last I heard). I don't think anyone is going to buy that as "maintaining" the 2.1.x series; I sure don't.

Delay the 2.3 release and spend more time on 2.2.2 (assuming that 2.2.1 is about to go out)?

2.2 did go out the door unfinished . But, again, we could have delayed it two years and it still would have been relatively unstable: there's just no substitute for getting thousands of users using a release.

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

You can fiddle what you call what we're already doing anything you want, but if a long-lived two-branch comes out of this, I quit . I do believe we should direct more effort into bugfix releases; that can't be done without taking away from something else, though (that's a trivial deduction: everyone is already overloaded).