New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
This crate should be v1.1+ #601
Comments
I don't think adding API and bumping the patch version is necessarily a violation of semver. Especially because crates specifying |
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:
Semver is supposed to let crates be ambivalent about the patch version, so it's technically correct for other crates to specify |
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 |
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. |
@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 |
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.The text was updated successfully, but these errors were encountered: