[Python-Dev] Re: Stability and change
Martin v. Loewis
06 Apr 2002 23:44:55 +0200
Alex Martelli <email@example.com> 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