Version selection in Cargo

[aturon]

When there are multiple ways to resolve dependencies, Cargo generally chooses the newest possible version. The goal of this post is to explain why Cargo works this way, and how that rationale relates to several recent discussions, including:

• Whether we should support a “minimal version selection” option, and if so how it should relate to CI and the existing ecosystem.

• Whether we should state a minimal Rust version in Cargo.toml in a way that affects dependency resolution.

• The work on vgo, a new package management tool for Go that explicitly opts for selecting the oldest possible version.

---

Read the post here

[carols10cents]

Rust’s rapid release process is based on the idea that most developers will keep their toolchain up to date, since each incremental update is small (as opposed to “big bang” updates on a much slower cadence). There is some risk that the stated toolchain approach will reduce incentives toward upgrading.

Hm, if most library authors are developers who keep their toolchain up to date, and state their up-to-date toolchain in their library, and users of the library want to use the library’s newest features, wouldn’t that increase incentives for users of libraries to upgrade their toolchain?

Or did you just mean that once you can state a toolchain, the social pressure will incentivize making your stated toolchain as low a version as possible, thus reducing the incentive toward upgrading for library authors?

[aturon]

Or did you just mean that once you can state a toolchain, the social pressure will incentivize making your stated toolchain as low a version as possible, thus reducing the incentive toward upgrading for library authors?

Yeah, that’s basically what I had in mind – but it’s possible that I’m making an incoherent argument here.

[scottmcm]

One thing that’s non-obvious to me is what a “core crate” means. At what point would a library say that it’s not a core crate?

Given something like an LTS, it feels like an implied statement that “if they want broad use [which of course they do], libraries should only be on LTS”. And being on LTS means you lose things like

since each incremental update is small (as opposed to “big bang” updates on a much slower cadence)

[kornel]

Personally, I always develop with latest stable, and prefer max versions of dependencies.

However, in CI I test with some older rustc version that I support. I would love to also have CI test with lowest versions of dependencies.

In practice I’d probably do this in CI:

- cargo build # required to catch misplaced `cfg(test)`
- cargo test --all
- cargo test --all --min-versions

So having max version by default, but min version as an option would work best for me.

[kornel]

As a library author, if I state a minimum required rustc version in my Cargo.toml, I’d like cargo to use rustup to switch to that older version for pre-publish compile check. I keep forgetting to do that manually.

[Eh2406]

So having max version by default, but min version as an option would work best for me.

That is what we have with nightlies. Speaking for myself, and not for the cargo team, I would be happy to help you set it up in CI.

[aturon]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.