This is kinda convoluted, but it bit me when I wasn't paying attention when updating rust's lock file. Here's a relatively small repro. Create a workspace with the following members and dependencies:
a → bitflags="0.9"
b → bitflags=">= 0.9, < 2.0"
c → bitflags="1.0"
cargo update will generate a lockfile that looks good (a→0.9, b→1.0, c→1.0).
cargo update -p c will downgrade b's copy of bitflags to 0.9! I'd expect it to leave it as-is.
The real-world example of this is in rust where these chains exist:
rustbook → ... → html5ever → .. → rand 0.3
rls → rayon → rayon-core → rand >=0.3, < 0.5
cargo → ... → rand 0.4
Updating cargo caused rayon's version of rand to downgrade. I didn't use rand in my example above because version 0.3 is a little odd in that it also depends on rand 0.4, but doesn't seem to be important and just complicates the example.
This is kinda convoluted, but it bit me when I wasn't paying attention when updating rust's lock file. Here's a relatively small repro. Create a workspace with the following members and dependencies:
cargo updatewill generate a lockfile that looks good (a→0.9,b→1.0,c→1.0).cargo update -p cwill downgradeb's copy of bitflags to 0.9! I'd expect it to leave it as-is.The real-world example of this is in rust where these chains exist:
Updating cargo caused rayon's version of rand to downgrade. I didn't use
randin my example above because version 0.3 is a little odd in that it also depends on rand 0.4, but doesn't seem to be important and just complicates the example.