An analysis of semver compliance in Rust finds accidental semver violations are common even in the most popular crates. Human error is not the cause, and better tooling is the way forward.
There are also plenty of purposeful semver violations. For example, serde makes basically no attempt to follow semver, and any pleas to do otherwise fall on deaf ears.
Not quite. Suppose instead of a single version of serde there’s now 46 versions like in https://crates.io/crates/parquet to be able to use instances derived in some other crate X you have to use the same version of serde. Now, how should a crate decide which versions of serde to support?
All 46 and all optional? Supporting that would be painful. Just the last one? crates.io is a cemetery full of dead crates, with this support strategy any handful of crates picked at random are not going to be serde-compatible with each other.
A better solution would be a better support for compile time reflection so serde doesn’t have to exist in its current state, but that’s got delayed (by big macro conspiracy :)
What’s more, there was a recent discussion about why the derive feature is recommended in serde, and one of the points brought up was that the versions for both crates basically have to be equal. I couldn’t help but wonder, would this be a problem if the releases actually followed semver? Theoretically, it shouldn’t matter what versions you use, as long as they’re above a certain minor version and the major versions match. But since everything is a patch, we have to pin the two crates together somehow.
There are also plenty of purposeful semver violations. For example,
serdemakes basically no attempt to follow semver, and any pleas to do otherwise fall on deaf ears.With the justification being “I can’t be bothered to decide what is breaking/feature/patch”, so hey, here’s a tool to tell you.
Not quite. Suppose instead of a single version of
serdethere’s now 46 versions like in https://crates.io/crates/parquet to be able to use instances derived in some other crateXyou have to use the same version ofserde. Now, how should a crate decide which versions ofserdeto support?All 46 and all optional? Supporting that would be painful. Just the last one? crates.io is a cemetery full of dead crates, with this support strategy any handful of crates picked at random are not going to be serde-compatible with each other.
A better solution would be a better support for compile time reflection so serde doesn’t have to exist in its current state, but that’s got delayed (by big macro conspiracy :)
What’s more, there was a recent discussion about why the derive feature is recommended in serde, and one of the points brought up was that the versions for both crates basically have to be equal. I couldn’t help but wonder, would this be a problem if the releases actually followed semver? Theoretically, it shouldn’t matter what versions you use, as long as they’re above a certain minor version and the major versions match. But since everything is a patch, we have to pin the two crates together somehow.