4 ms·

I have seen many discussion through the years about how important semantic versioning is. Then every project seems to end up using their own definition of break

I have seen many discussion through the years about how important semantic versioning is. Then every project seems to end up using their own definition of breaking change, which makes semantic versioning seem overhyped as a universal tool (although probably useful for each individual project because they know exactly what it entails).

burntsushi 4y ago
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!
kibwen 4y ago
> every project seems to end up using their own definition of breaking change 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.
pjmlp 4y ago
As Ritch Hickey puts it semantic version is meaningless in practice. https://youtu.be/oyLBGkS5ICk https://youtu.be/oyLBGkS5ICk

burntsushi 4y ago

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!

kibwen 4y ago

> every project seems to end up using their own definition of breaking change 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.

pjmlp 4y ago

As Ritch Hickey puts it semantic version is meaningless in practice. https://youtu.be/oyLBGkS5ICk https://youtu.be/oyLBGkS5ICk