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.
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 :)
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 :)