[Python-Dev] Re: Stability and change

[Tim Peters]

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

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