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

Guido van Rossum guido@python.org
Sat, 06 Apr 2002 20🔞45 -0500

[Aahz]

I'm kind of in agreement with Tim; I don't think this buys much. Seems more important to me to specify process than stability per se.

I think our process is impeccable. What's missing is clear guidelines for the users. Maybe Alex is right and the Linux odd/even distinction is clearer than using micro release numbers to indicate bugfix/stable releases.

What I suggest is that instead of

major.minor.bugfix we do major.minor.enhanced.bugfix

Ah, yuck. I really don't want to start using more dots. Too confusing.

This way, only major.minor releases can introduce actual language changes, but enhancement releases can pick up library changes.

I don't see how this helps.

If this sounds at all workable, I recommend issuing a quick BDFL pronouncement changing 2.2.1 to 2.2.0.1.

No. :-)

Then what we might try for a 2.2.1 release is making the new boolean type a module that people can start using.

No again. (Banning the new bool type to a separate module is a waste of time.)

I am also a bit amused because an early draft of PEP 6 did try to address this issue, but you and Tim dissuaded me. I think both of you were right back then, but it's still kind of funny to see it picked up a year later.

We still seem to be disagreeing on how to do it. :-(

[Barry]

From my own perspective it seems that 2.1.x is viewed as the stable release family, and each micro release reaffirms its stability.

That's about right. Maybe we should continue to promote 2.1.x and relegate 2.2 to the bleeding edge? A simple rearrangement of the website might be sufficient.

That's a good thing. That 2.2.x is viewed as more experimental is simply caused by the new type/class stuff, and I don't think there's much marketing you could do to change that perception. Maybe 2.2 should have been called 3.0 .

Or maybe 2.3 should become 2.2.3. <0.5 wink>

[Martin]

[quoting Alex] > 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.

Is that actually a problem (or, the problem)? I.e. if somebody finds that 2.2 is "unstable", does it ever happen that, to solve a problem, something has to be taken back? The typical problems seem more to be in the area of bugs: a bug was fixed, and this fix broke existing code, or a feature was introduced, and that broke existing code.

Usually the latter. When fixing a bug breaks code, it can mean two things: (a) the fix was to introduce a feature (sometimes the right thing to do); or (b) the bug was so pervasive that work-arounds became widespread, and the fix breaks the work-around. Both are relatively rare (but have happened).

But new features regularly break existing code: either by introducing a new keyword (e.g. yield), or by changing results in certain situations (e.g. str(1==1), or nested scopes), or by taking away old crutches (e.g. import * inside a function). There are many more examples, despite the fact that in each of these cases we've tried to do our best to minimize breakage.

In either case, it is desirable to keep the existing fix, and the new feature, but to find a way to let the old application continue to work.

I would think that the best way to keep old code running is to keep the old interpreter around. Maybe one problem is that we've been installing each new version as "python" by default? Even on Windows that can be made to work, as long as you find a way to start your program with a specific Python version: you can't use #!/usr/local/bin/python2.2 and double clicking .py will invoke the most recently installed version. (Hm, would it be totally outrageous to let Python itself on Windows check for a #! line, and when there is one that names an existing Python interpreter that's not the current one, simply exec that one on top of the current one???)

The need to phase out new features that turn out to be a mistake is relatively rare, IMO; instead, there is a stronger desire to phase out old features that have been superceded by newer ones.

IMO the most common breakage is when a new feature uses up a tiny portion of some namespace that used to belong to the application.

Or are you just hoping that booleans will be removed in 2.3.1 again :-?

Fat chance. :-)

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