3 ms·

Your reply feels unnecessarily confrontational / aggressive, but I’ll respond anyway. > Everyone else just maintains backwards compatibility. Name one piece o

Your reply feels unnecessarily confrontational / aggressive, but I’ll respond anyway. > Everyone else just maintains backwards compatibility. Name one piece of software of substantive size and with a history longer than a couple years, which never had a backwards compatibility break ever? Just in case you can name one, then name two instead. Contrary to your statement, 99.99999% of software has a backwards incompatible change at some point. What’s a good way to indicate that to your end users? Semantic versioning. > Nobody asked you to "improve" you library by breaking it. So if a major bug is found after release, one should never fix it? Fixing a bug could easily lead to a backwards incompatible break, if nothing else because someone was depending on that buggy behavior.

lugg 7y ago
Asking me to name perfect records is impossible and unnecessary. You do not have to maintain backwards compatibility forever in all cases. My only argument is that it being the default approach to changing software isbwhat offers the best results without the added cost of semantic versioning and all the treeshaking failures that comes along with it. Linux userland APIs, C/C++, WordPress, Clojure are all pretty successful software that maintain backwards compatibility as some form of priority and commitment with varying degrees of success. None of which get much lament for doing so compared to say nodejs/JS/npm which are routinely the laughing stock of the industry for their lack of platform stability. > Bug fix Your point about these is pretty funny because these breaking changes are specifically allowed by semver as minor patches. Which was kind of my original point here it's a flawed spec that offers no real safety at great cost.