🔖 Semantic Versioning is a terrible mistake [it encourages breaking API changes: “If you need to make a breaking change to your API, it means you screwed up”] | The Reinvigorated Programmer https://reprog.wordpress.com/2023/12/27/semantic-versioning-is-a-terrible-mistake/ #BookmarkShare
@dltj hard disagree (like the first couple of commenters) - "SemVer" absolutely does not encourage breaking API changes - IMO/IME, it just documents them in a clearly visible way. Poor developer culture ("move fast and break things" or "everybody is a developer") is what encourages breaking API changes.
@jimnauer by providing a mechanism to announce breaking changes, breaking changes are encouraged. If it was harder for downstream developers to know when breaking API changes happen, the creators would be more careful, lest their software be seen in a more unkind light.
It is cultural, too. The library project @mike references in his post has not been able to cultivate careful backwards compatibility in a trade off for faster feature development.
@dltj
That *semver* is providing a novel way of declaring incompatibility is a pretty wild claim, because not only is there also release notes, the practice of putting semver-like version info in file names is really old, dating back to at least the mid 80[1] but probably much older than that.
No, I think this is a JavaScript dev with Stockholm syndrome who blames the messenger that reveals the reality of how sloppy the JS dev culture is. This is the dev culture that had thousands of build and deployment processes fall over because left-pad was removed; to blame aggressive breaking on semver is silly.
[1] This publication from 2000 references a text from 1987 that talks about naming libraries with major and minor versions, defining "major" in basically the semver way: https://www.usenix.org/legacy/publications/library/proceedings/als00/2000papers/papers/full_papers/browndavid/browndavid_html/index.html
@jimnauer @mike
