3 ms·
I don't know the details in rust's case, but I wouldn't consider it a violation of semver if the code which broke in a minor update was doing bad things (maybe
by jjnoakes 10y ago
I don't know the details in rust's case, but I wouldn't consider it a violation of semver if the code which broke in a minor update was doing bad things (maybe accidentally exploiting a bug or limitation in the language or implementation, probably by violating some requirement that wasn't checked properly, etc) and simply couldn't be correct code if left alone.
- panic 10y agoHow do you define a "bad thing"? The semver spec is quite clear about "even the tiniest backwards incompatible changes" (http://semver.org/#if-even-the-tiniest-backwards-incompatible-changes-to-the-public-api-require-a-major-version-bump-wont-i-end-up-at-version-4200-very-rapidly http://semver.org/#if-even-the-tiniest-backwards-incompatibl...) requiring a major version bump.
- Manishearth 10y agoRust has its own definition of what it defines to be stable. Soundness fixes and bug fixes do not count, though as much as possible they will try to fix them in a way that breaks very little. http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html
- lifthrasiir 10y agoCargo does not (yet) ensure that the library maintainer did follow the semver's doctrine.
- Argorak 10y agoBut there are people working on it. https://github.com/semantic-rs https://github.com/semantic-rs
- jjnoakes 10y agoIt may not be considered a backwards incompatible change to rust if it no longer compiles invalid code. If the code never worked correctly, but silently compiled, one would think a breaking change was welcomed.
- steveklabnik 10y agoSemver does not define what a "compatible" vs "incompatible" change means, though. Manish linked to how we define it, but SemVer specifically leaves that up to the project.