I personally use semver where I can, especially when I intend for others to use my code, because it is exceptionally good at signaling "this release may require some manual changes or extra work." And because it's good at that, tooling has been built up around it that makes it ever better.
Of course, semver has exceptionally small bandwidth. And sometimes people can disagree about what a breaking change is (does increasing the toolchain version required to build your library constitute a "breaking change?"). And sometimes behaviors of code are so difficult to specify that breaking changes may happen unintentionally.
And yes, things get overhyped. That's been happening with all sorts of things in tons of different contexts. I fail to see how it's an interesting remark in this case.
Some people have argued that the main point is about being machine-readable. But that’s not relevant as long as the consumers are all on the same page (users of NPM probably don’t have to care that much about what definition Rust uses).
> Of course, semver has exceptionally small bandwidth.
Yes. Just a flag in the breaking-change case. Maybe a data exchange format would have been better if we really wanted to communicate precisely what we have changed (again, if machine-readability was ever a concern).
> And sometimes people can disagree about what a breaking change is
The Semver 2.0 page defines it as a change to the public API (or “the API” since if the API is not public then it doesn’t even matter). So if you define your API then you should know what it would take to “break” things.
> I fail to see how it's an interesting remark in this case.
Sorry to have bothered you. Again.
You see this every time with semver. Is a bugfix that changes behavior someone relied on breaking? Is a performance drop? Is a performance improvement? All of those can break my code!
This is natural. People naturally have different notions of what a breaking change is. For example, in C++ land, an incompatible change to an ABI is a breaking change, whereas in Rust land there's only a handful of types with stable ABIs. What "breaking" means will differ by language and ecosystem, and the goal is to find a useful definition for your particular context. Semver acknowledges this, which is why it deliberately refuses to strictly define what constitutes a breaking change.
Let's also keep in mind that every language makes tiny breaking changes whenever they think they can get away with it, including legendarily-stable enterprise languages like Java and PHP (look up the "compatibility guides" that accompany language releases). And that's not a bad thing; engineering is a science of tradeoffs.