34
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 07 Sep 2023
34 points (100.0% liked)
Rust
5938 readers
1 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
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.