[Python-Dev] Re: Stability and change

[Martin v. Loewis]

Alex Martelli <aleax@aleax.it> writes:

> Your freedom to experiment as well as public perception might be
> enhanced by some explicit mention that the first (.1) stable release 
> does not guarantee 100% compatibility with the immediately
> previous bleeding-edge/experimental release, so you can (within
> some common-sense bounds) try putting something in 2.X and
> then taking it away in 2.X.1 if it didn't work.  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. 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.

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.

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

Regards,
Martin