MSRV-dependent dependency version resolution

[newpavlov]

Based on RFC 2495 Rust now supports the rust-version field, which currently works as:

If the currently selected version of the Rust compiler is older than the stated version, cargo will exit with an error, telling the user what version is require

This behavior is not ideal. If a project depends on crate foo v0.1.0 with MSRV 1.56, then releasing crate foo v0.1.1 with MSRV 1.60 will break build of the project on older toolchains after simple cargo update. Ideally Cargo would select foo v0.1.0 on older tolchains, thus preventing the breakage.

RFC 2495 has described MSRV-dependent version resolution as a potential future extension. This issue is intended for design discussions and tracking implementation progress of this feature.

Third-party support

• Take rust-version into account when updating lock file / manifest dependabot/dependabot-core#5423
• Update cargo dependencies based on `rust-version` renovatebot/renovate#26060

---

This has been approved as RFC #3537.

Implementation by stabilization milestone

• Improve the cargo install error (fix(install): Suggest an alternative version on MSRV failure  #12798)
• Improve documentation around rust-version (docs: Provide pointers for MSRV #13056)
• cargo-add (feat(add): Stabilize MSRV-aware version req selection #13608)
  • cargo add support (cargo add takes package.rust-version into account when no version-req is specified #10653)
  • Infer users rust-version from rustc -V (feat(add): Fallback to rustc -v when no MSRV is set #13516)
• Attempt to report the MSRV error top-down, rather than bottom up (fix(msrv): Report all incompatible packages, not just a random one #13514)
• cargo update keeps user informed when using old versions (feat(update): Tell users when they are still behind #13372)
• Report newly held back dependencies on all commands #13539
• Resolver (feat: Stabilize MSRV-aware resolver config #14639, feat(resolver): Stabilize resolver v3 #14754)
  • Prototype (feat(resolver): **Very** preliminary MSRV resolver support #12560)
  • Switch resolver to "prefer" rather than "enforce" (fix(resolver): Prefer MSRV, rather than ignore incompatible #12950)
  • De-prioritize dep versions without rust-version (fix(resolver): De-prioritize no-rust-version in MSRV resolver #13066)
  • Infer users rust-version from rustc -V (feat(resolve): Fallback to 'rustc -V' for MSRV resolving #13743)
  • Existing --ignore-rust-version support (feat(reslve): Respect '--ignore-rust-version' #13738)
  • --ignore-rust-version support for cargo update / cargo-generate-lockfile (feat(cli): Add --ignore-rust-version to update/generate-lockfile #13742)
  • Config support for controlling MSRV-aware resolver #13540
  • Add resolver v3 (feat(resolver): Add v3 resolver for MSRV-aware resolving #13776)
  • Verify resolver 3 doesn't change cargo-install (fix(msrv): Put MSRV-aware resolver behind a config  #13769, fix(install): Don't respect MSRV for non-local installs  #13790)
  • Verify cargo update --precise can select incompatible versions (fix(msrv): Put MSRV-aware resolver behind a config  #13769)
  • Enable resolver v3 with Edition 2024 (feat(resolver): Add default Edition2024 to resolver v3 #13785)
  • fix(resolve): Improve multi-MSRV workspaces  #14569
  • test(install): Verify 2024 edition / resolver=3 doesn't affect resolution #14724
• Have lockfile format version respect --ignore-rust-version (see feat: respect rust-version when generating lockfile  #12861)
• --update-rust-version support
  • cargo add
  • cargo update
  • cargo generate-lockfile
• Turn MSRV error into a lint (blocked on User control over cargo warnings #12235)
• "auto": Add field with cargo-publish behavior (see also Cargo should set "rust-version" for me #11451)
• Update cargo new template

Changes from RFC

Unresolved questions

• cargo add and the resolver have different behavior for unset rust-version, see fix(resolver): Treat unset MSRV as compatible #13791

Deferred

• Determination for what cargo install should do, see also Respect rust-version when selecting a version for cargo install #10903

[djc]

I think this probably makes more sense in the Cargo repository, since version resolution happens in Cargo -- might even make sense to do an RFC for it. @ehuss @Eh2406 what do you think?

I can see the attraction of this feature, but I'm also worried about it -- if this behavior doesn't come with a warning, it's trivially possible that downstream crates no longer get updated to upstream dependencies that fixed security vulnerabilities, for example. While I usually deploy cargo-deny in CI to make sure I'm aware of this, as long as something similar is not integrated in Cargo it would be a little scary that semver-compatible updates no longer flow as freely as they used to.

[newpavlov]

Yes, having a Cargo warning for cases when there are dependency updates with incompatible MSRV would be a good feature.

As for security vulnerabilities, I think it should be solved by advisories like RustSec and by yanking affected versions. Also note that today crates can have minor (for pre-1.0, major otherwise) version updates with security fixes which do not get ported to older releases. So I don't think that the proposed MSRV-dependent version resolution is fundamentally different from the existing status quo in this regard.

[Eh2406]

Transferred to Cargo.

IMO one of the big problems blocking this is the error messages. The current Resolver has pretty bad messages, it just reports on the last thing that did not work. So In effect the Resolver will just ignore all versions with a different MSRV leaving no record of why newer versions were not considered. This may be on the list of things to consider when/if we use PubGrub. But that is just my opinion.

[leo60228]

Is this actually a good idea? I feel like rust-version should solely be a safeguard, and not actually affect behavior. IMO pinning a Rust version without pinning dependencies is user error, and it's better for this to be a hard error instead of doing what might be the wrong thing.

[gilescope]

broken code doesn't help anyone. If cargo update / upgrade gives warnings that your rust version is too old to bring in all the latest updates then people will be more likely to run cargo upgrade as they are more likely to get a result that works. Pragmatically some stuff upgraded is better than nothing upgraded.

[newpavlov]

@leo60228

Is this actually a good idea?

It was my main motivation for writing the MSRV RFC. Without it I (and many others) consider bumping MSRV a breaking change, since otherwise we risk breaking people's builds on older toolchains (e.g. think of Rust packaged with Debian). Printing an error is just slightly improves ergonomics, no solves the problem at the root.

[djc]

I think most maintainers have stepped away from the idea of MSRV bumps requiring a semver bump. Even fundamental things like serde have done it. Instead, just keep a conservative enough MSRV for your crate's audience.

[asomers]

I think most maintainers have stepped away from the idea of MSRV bumps requiring a semver bump. Even fundamental things like serde have done it. Instead, just keep a conservative enough MSRV for your crate's audience.

But keeping "a conservative enough MSRV for your crate's audience" is not_possible if your upstream dependencies don't do the same. If upstream crates raise their MSRV without a major version bump, then you have little choice but to follow suit. As @leo60228 suggested you could pin those crates versions to before their MSRV bump, but that causes a different problem: Cargo refuses to build two semver-compatible versions of a single crate in a single build. That can result in downstream users' builds breaking, even if they don't care about MSRV. So Rust really does need an MSRV-sensitive resolver.

[matklad]

pinning a Rust version without pinning dependencies is user error, and it's better for this to be a hard error instead of doing what might be the wrong thing.

One way to resolve this concern is to make the behavior opt-in. By default, behavior is at is today (modulo a better error message), but you can pass --rust-version flag to commands like update or generate-lockfile to request resolution at a specific version.

[djc]

But keeping "a conservative enough MSRV for your crate's audience" is not_possible if your upstream dependencies don't do the same. If upstream crates raise their MSRV without a major version bump, then you have little choice but to follow suit.

In theory, this is true. In practice, I've found that upstream maintainers have usually been happy to accomodate my requests for changes to allow a more conservative MSRV -- just a matter of (a) being aware when changes happen and (b) engaging with upstream to voice your concerns/discuss trade-offs.