5 ms·

Not sure what relevance that has here. Semver is just a tool to manage communication among a group of decentralized humans. Communication is always hard. I per

Not sure what relevance that has here. Semver is just a tool to manage communication among a group of decentralized humans. Communication is always hard. 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.

avgcorrection 4y ago
> Semver is just a tool to manage communication among a group of decentralized humans. 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.
- joshuamorton 4y ago
  And the rust team has defined their api, and some subset of users disagree. 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!

avgcorrection 4y ago

> Semver is just a tool to manage communication among a group of decentralized humans. 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.

joshuamorton 4y ago
And the rust team has defined their api, and some subset of users disagree. 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!