[Python-Dev] Re: Stability and change

[Guido van Rossum]

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

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