Alex Martelli firstname.lastname@example.org 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 :-?