Doc claim that feature removal is SemVer Major seems out of date?

[workingjubilee]

Motivated by the resolver docs on features, I discussed the way that cargo handles feature resolution on Zulip: https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/How.20old.20is.20this.20feature.20resolving.20quirk.3F/with/523022575

From this I found out about the PR that introduces the resolver's backtracking on a failure to resolve features, allowing you to remove features without breaking dependents, as while they cannot upgrade, they also will not be forced to upgrade: #5000

I carried on with my day for... many days... until I found out about Cargo's docs on semver compatibility. I found out because cargo-semver-checks is following this advice, and has a lint called feature_missing, which is defined as SemVer major breakage in accord with this guidance. I have opened an issue about this: obi1kenobi/cargo-semver-checks#1285

I hope I understand the resolver's behavior correctly in thinking that feature removal, while maybe not SemVer patch material, would be sensible with a SemVer minor increase? It at least does not seem like it should be treated as unequivocally major version breakage for the vast majority of crates that have a sufficiently high MSRV to require a rustc that ships with a cargo that can handle this.

[hanna-kruppe]

If I understand correctly: releasing foo v1.1 which removes a feature that existed in foo v1.0 won't immediately break dependents that do cargo update foo, but the build still breaks if something else forces selecting foo v1.1. Since Cargo won't select two semver compatible versions of the same library, automatically preventing a dependent from updating to a supposedly semver-compatible release isn't much better than breaking their build if they do get the newer version. So I'd still call this semver-breaking in spirit and in practical effect.

[epage]

I think independent of the how the resolver acts, this is SemVer major.

cargo update is a tool and our treatment of SemVer is not limited to how a tool acts. If I manually update the version requirement, my build will break. If we pulled in cargo upgrade, that would break. There has also been talk of whether this is the right resolver behavior. Granted, we'd have to figure out the right transition plan if we changed it but that isn't a transition on the meaning of SemVer but on Cargo's resolver implementation.

[workingjubilee]

In practice, the fact that the resolver behaves this way allows removing implementations that have been deprecated, sometimes for an entire decade, without actually breaking anyone. It is very often that people actively working on things don't actually require a feature because it was long since outmoded, but there may be code in the very long tail of software that does use it but needs updates for other reasons.

If anyone is manually manipulating the Cargo.toml then they can create a lot of other problems for themselves like specifying yanked versions, can't they?

[hanna-kruppe]

If a kind of change is generally breaking, but in specific cases and circumstances it’s fine in practice and the lesser evil compared to a semver bump, that doesn’t mean that kind of change isn’t a breaking change in general. Imagine if libc removed extra-traits in its next 0.2.x release — that would cause a lot of breakage. Crate authors can always ignore the Cargo docs and cargo-semver-checks lints if they’re sure they know better.

Keep in mind, however, that downstream projects may wish or be forced to combine very old versions of library A with new versions of library B in the same dependency graph, so I’m generally very skeptical of “it’s been deprecated for years” as rationale for “it’s not really breaking”. Bending semver works best when there was never any real code that would be broken. Semver is not about you(r direct dependents).

And no, you can’t select a yanked version just by editing Cargo.toml, you have to edit the lockfile by hand or with cargo update —precise.

[ehuss]

The cargo team talked about this today and decided to close this issue. I think there is a general intention that semver compatibility extends to updating the minor version in Cargo.toml. That is, if you have foo = {"1.0", features=[...]} and you update it to foo = {"1.1", features=[...]}, that should not break.

There is also a concern that removing a feature sets an upper-bound for which minor versions are allowed, which can cause problems if there are multiple packages depending on it in the tree (all specifying slightly different minor versions), which can cause an error due to conflicts.