cc-rs
cc-rs copied to clipboard
rust-lang
This crate should be v1.1+
Since cc 1.0.0 the method is_like_msvc has been added, which is an API change that should get a semver-minor bump.
Crates that specify they use cc = "1" (e.g.) may not actually be compatible with cc 1.0.0.
I don't think adding API and bumping the patch version is necessarily a violation of semver. Especially because crates specifying cc = "1" will still get the most recent cc in 1 series and potentially miss this anyway. What is necessary is more widespread testing of -Zminimal-versions across the ecosystem.
Addition of a new public API without bumping the minor version is very specifically called out as a violation of semver in the semver spec:
Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.
Semver is supposed to let crates be ambivalent about the patch version, so it's technically correct for other crates to specify cc = "1" when only 1.0.x versions of cc exist. If cc was at 1.7.20 or such, then it'd be fair to require crates to specify cc = "1.7" or whatever they depend on.
I strongly prefer the 1.0.LARGENUM numbering and it's how I have been doing my crates too. The saving of time by not needing to adjudicate whether every single change is a feature vs a bugfix outweighs any purported benefit of a different scheme. I also appreciate not having a semver zealot at my throat about every borderline case.
If someone declares their dependency requirement imprecisely because semver tells them they technically can't require anything from a newer patch, then they are being obtuse. They need to fix their dependency requirement to declare the smallest version that they are okay with being pulled in.
I understand that dealing with borderline cases in semver is annoying, especially things involving changes in behavior, compiler compatibility, or changes to obscure parts of the API that probably nobody uses. But this case is not any of these. It's very clear, both from semver spec and technical perspective. It can even be objectively machine-checked: there has been a new public method added. It's an additive change that makes users of the method incompatible with any previous version of the crate, and semver specifically deals with this case.
Users of Cargo expect crates to follow semver, even when authors don't like semver.
I don't know what you are advocating. Whether the one case is very clear is irrelevant – the existence of a very clear case does not eliminate the large net negative that would come with dealing with a bunch of borderline cases. Only the current approach followed by this crate eliminates all adjudication of borderline cases. Even versioning only the very clear cases as minor versions is strictly worse than the current approach because people will happily fight you over what is "very clear" to them.
I'm not really advocating for anything new, merely reporting a bug in this crate's version. Cargo/crates.io already uses SemVer. Nothing about this specific issue should be controversial. Even Cargo-flavored relaxed view of SemVer uses minor versions (e.g. addition of new public items).
Conversely, I'm not sure what you're trying to achieve here. I get you're annoyed by borderline SemVer cases, or perhaps dislike the concept of SemVer entirely, but are you advocating for Rust/Cargo to switch from the SemVer to your versioning method? That's a material for an RFC, not something to argue with me in the comments of the cc crate.
I am advocating for the cc crate to not change in response to this issue — I think "too bad" is roughly the appropriate response.
Anyone is free to redistribute the code of my MIT licensed crates under a different versioning scheme, but so far nobody has found different versioning beneficial enough to pursue that.
Come on, you know that "you can fork it" is not a reasonable response when the issue is concerning crates fundamental to the crates.io ecosystem.
Let's move the discussion to your crate
@dtolnay , serde recommends using the 1.0 version as the version boundary, not the specific patch version. So I think this is legitimate bug, because cargo treats versions in Cargo.toml as semver ranges. Cargo.toml specifies, that [package]/version is a semver number. serde does not follow these requirements. This is a problem. Simply turn a blind eye will not eliminate it magically.
