MSRV

David

"support"

• Jacob:
  • Norms like semver where there is a default and people document otherwise (whether msrv is breaking, features that are unstable, etc)
  • This makes the norms legible to cargo and so people can leverage them
  • What is part of toolchain?
    • Everything versioned with rustup
    • Is rust-analyzer part of the toolchain?
    • It is generally received through other means but can be received through rustup
    • Sympton
      • Using rust-analyzer out of rustup with their MSRV version but not compatible with editor
        • rust-analyzer hacks in support for a feature until there is a native version in vscode and then its removed
        • https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md
        • So features might not work
      • rust-analyzer has rust-std-version-specific hacks
        • Only works with current stable version of rust std
      • proc-macro expansion server
        • shared between rustc and rust-analyzer
        • abi check
    • Confusion
      • Thought we were having people use old toolchain
    • Concern:
      • People think they are taking on more of a burden to support an MSRV that its not worth it
      • Because they have to support the old r-a that doesn't actually work?
• auto
  • switches from bimodel to continuous
  • without an MSRV, latest stable is right assumption, not what was used at publish
    • in MSRV thread, people are usually asking for the opposite, "if I fit I sits"

Why latest deps with MSRV

• Amazon
  • Most are on new but the glibc problem is an issue
  • Targeted latest and oldest
  • Do local and then in CI find out that it fails
  • Still want latest
    • Go to the extreme of an auto-rebasing branch with changes to make it work
• WHy latest? keep number of dependencies

Security

• Ensure people get security updates

epage thoughts

auto:

• cargo news defaults are not static and not RFC-level
• If you don't want to have stale deps, you need deps with an explicit MSRV policy
  • If there is no policy, at any point, what was compatible might change
  • While people don't regularly go actively looking for the latest Rust features and use them on day one
    • When you spread this across your development tree, your more likely to hit dependencies that do leverage new features
    • If nothing else, clippy will happily update your dependencies to use the latest stdlib features
• To publish, you already have to edit your Cargo.toml
  • This provides an opportunity to notice and remove
  • I've talked about going an extra step with making cargo new set publish = false and us changing the default over time
  • See https://github.com/rust-lang/cargo/issues/6153
• cargo new will prefer what is in workspace.package.rust-version
  • However, there is no proposal what to call "unset" to be able to inherit it.
  • I also don't think we should solve that as part of this but people should instead set an MSRV
• If dep keeps the default, is that really a dep you should be relying on if you have an MSRV?

jacob's thoughts

• auto is a smart way of freezing the index for a given rust release
  • When stuck behind temporarily, this is effectively what people want
• For intersection of user who sees themselves on latest with depednencies that might update MSRV aggressively than otherwise due to auto
  • How often is this on both sides?
    • Common on left
    • Unknown on right
  • How much of a problem with this?
• How much of a delay from corp infrastructure to keep up with 6 week release cycles?

Rewritten concerns

Why not auto (quotes are not direct but to highlight I'm speaking in someone else's voice)

• One of the concerns with an MSRV-aware resolver is "I will 'silently' be on old versions"
  • "Updates happen in CI, I will never see warnings, making this silent"
    • "What if one has a fix for a CVE?"
  • "I would rather have a noisy or bad error than accidentally be on a ancient, unsecure version"
  • "I trust my direct dependencies to have an MSRV. That trust does not extend transitively to all of my indirect dependencies. Those are the cases where I'm concerned with them using auto and me being behind silently"
  • For this audience, they feel that if someone has an MSRV, it is likely to be much older than "stable" such that they aren't too far behind.
  • auto breaks this assumption.
  • However
    • Its a big, incorrect assumption that someone having an MSRV means it will be far back enough to be useful. this is a big assumption. Clap only has an N-2. Even if clap has an LTS, it will likely involve community support to backport changes. If you and a dependency have a mismatch in MSRV expectations, then you will hit this
    • This problem also exists for semver and in general people need some way to be tracking their dependencies generally and CVEs specifically
    • This allows you to assume that a package's MSRV is fine for you (because its unset) and they break it in the next release
      • If you are using a dependency on an unsupported Rust toolchain, there should be a more explicit acknowledgement of that
    • This is assuming a worst case that auto will proliferate among indirect dependencies
      • cargo new does give precedence to the workspace MSRV, so if someone has a "bigger" project which is likely correlated with both a workspace and an MSRV, then they won't accidentally fall into this
      • You already have to modify a manifest to publish, so new users can fall into this (and should) but established users will be more likely to change it if they intend to
• While the RFC emphasizes that an MSRV policy is a concious choice, auto deviates from that and makes it a "if it works"
  • This overloads the field to mean both "what I support" and "what builds", making the intent unclear
  • As a consequence, users could assume they are being offered "support" where it isn't intended, negatively impacting the maintainer and frustrating the user in the process
  • However
    • Manifests need to balance nuance with simplicity
    • For users with auto, it represents what they are using which is what they support.
    • It is an incorrect assumption to assume all past versions are fully supported and rarely do maintainers support them.
      • This is different than just yanking all the old versions (and generally I feel like people are frustrated with those that do that)
• Split out auto from the rest
  • Let's see how improving the MSRV experience does in making people more willing to commit to an MSRV that it might remove the need for auto
    • However,
      • if auto is more geared towards novice or applications, then this doesn't really tell us much as they will be unset now and after this experiment

One possible way of getting both is recording the published rust version separately and then allowing an optout at resolution time

Mixed MSRV

2024-09-04

https://github.com/rust-lang/cargo/issues/14414

Ed and Josh

Agree that current mixed behavior is not good

Do we report?

• Yes
• https://github.com/rust-lang/cargo/pull/14471

Do we agree that path-aware MSRV resolution would be ideal?

• fallback can't
• deny could but doesn't work for everyone

Other options

Pick newest

• Worst of both worlds
• Hardest is oldest MSRV and thats not what we're helping with

Multiple

• Picks lower than needed
• Only when version req is liberal enough

Concern: a naive maintainer with workspace has a contributor who pushes for a certain MSRV

• existing vs new MSRV are different because of workspace inheritance
• CI is a pain but cargo hack helps

2024-09-11

one MSRV among many no-MSRV is more predictable and comprehendible that that one applies to all.
But middle MSRVs applying to unrelated is more surprising.

This even applies to 2 MSRVs, not just 3+.
Having no MSRV communicates differently than having an MSRV, even if its rust-version = "toolchain"

Built-in cargo hack?

• don't unify among my workspace

Opt-out of unify resolve and UI improvement

Why we didn't update a compatible

Case 1

• Wasn't selected
• MSRV-resolver heuristic failed you,
• Version requirement upper bound
• Missing feature

Case 2

• MSRV-resolver herustic correctly held version back

Case 3

• Version incompatible, direct dep

Case 4

• Version incompatible, indirect dep

Option

• Always print the unchanged line for Case 1, even if unchanged
• Also, always print the unchanged line for Case 2, even if unchanged
• Change the status message on non-verbose or add a separate one, to mention MSRV