Re:Abstracting over ownership in Rust with higher-rank type ...
by kibwen on Sunday September 11, 2022 @11:54AM
(#32800693)
> 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.
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.