> So you can have exactly the same problem with B depending on [email protected] and C depending on [email protected] in Cargo. I believe the reason for only supporting concurrent versions with different major versions (to use the paper's parlance) is because packages should have incompatible APIs anyway.
Presumably you mean compatible rather than incompatible there?
The rust ecosystem standardised on semver. This means it is perfectly allowed to use 1.2 in place of 1.1. While you can specify upper bounds for the depdnency ranges, that is extremely uncommon in practice. Instead the bounds are just “1.1 or newer semver compatible" etc.
See https://semver.org/ for more on semver (but do note that Rust uses a variation, where it also applies to the leading non-zero component of 0.x).
> Presumably you mean compatible rather than incompatible there?
I've edited for clarity, I mean "because packages with different major versions should have incompatible APIs anyway."
> While you can specify upper bounds for the depdnency ranges, that is extremely uncommon in practice.
In https://github.com/rust-lang/crates.io-index I count just under 7000 upper bounds on dependency ranges that aren't just semver in disguise (e.g. not ">=1.0.0, <2.0.0"):
So it's definitely used. One person's non-breaking change is another's breaking change https://xkcd.com/1172/