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:
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?
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)
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.