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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4