-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Description
Currently, if there is a new release of a package that removes a required feature, then cargo update
will silently do nothing. This can be a confusing experience because if the user looks at crates.io and sees there is a newer version, it can be difficult to understand why it is not working.
I believe that removing a feature is a breaking semver change, but not everyone knows this or is diligent about managing correct version bumps.
I think cargo update
should display a warning if the "newest" candidate is not used because it is missing a feature.
It should probably ignore intermediate candidates, for example starting from version 0.1.0, publish bad release 0.1.1, publish fixed release 0.1.2, then updating from 0.1.0 to 0.1.2 should not produce any warnings.
There are other edge cases to handle (like being able to update from 0.1.0 to 0.1.1, but not 0.1.2).
The following is a test to demonstrate the scenario. The warning at the bottom is just a suggestion, the actual warning will likely be a little different.
#[cargo_test]
fn update_with_missing_feature() {
// Attempting to update a package to a version with a missing feature
// should produce a warning.
Package::new("bar", "0.1.0").feature("feat1", &[]).publish();
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.1.0"
[dependencies]
bar = {version="0.1", features=["feat1"]}
"#,
)
.file("src/lib.rs", "")
.build();
p.cargo("generate-lockfile").run();
// Publish an update that is missing the feature.
Package::new("bar", "0.1.1").publish();
p.cargo("update")
.with_stderr(
"\
[WARNING] a newer version of package `bar` is available (`0.1.1`), \
but it does not include the required feature `feat1`, so it will not be updated
",
)
.run();
// Publish a fixed version, should not warn.
Package::new("bar", "0.1.2").feature("feat1", &[]).publish();
p.cargo("update")
.with_stderr(
"\
[UPDATING] `[..]` index
[UPDATING] bar v0.1.0 -> v0.1.2
",
)
.run();
}