Allow verifying published MSRV #216
Labels
C-enhancement
Category: A new feature or an improvement for an existing one
help wanted
Call for participation: Help is requested to fix this issue
Comments
|
Seems reasonable to me. |
taiki-e
added
C-enhancement
bors
added a commit
to rust-lang/cargo
that referenced
this issue
Oct 8, 2023
Set and verify all MSRVs in CI ### What does this PR try to resolve? Allow us to advertise an MSRV for all public packages, unblocking #12432. Packages are broken down into two MSRV policies - Internal packages: `rust-version=stable` - Public packages: `rust-version=stable-2` To support this - RenovateBot will automatically update all MSRVs - CI will verify all packages build according to their MSRV Since this takes the "single workspace" approach, the downside is that common dependencies are subject to each package's MSRV. We also can't rely on `-Zmsrv-policy` to help us generate a lockfile because it breaks down when trying to support multiple MSRVs in a workspace ### How should we test and review this PR? Per commit ### Additional information #12381 skipped setting some MSRVs because we weren't sure how to handle it. For `cargo-credential`, we needed to do something and did one-off verification (#12623). `cargo-hack` recently gained the ability to automatically select MSRVs for each package allowing us to scale this up to the entire workspace. I don't know if we consciously chose an MSRV policy for `cargo-credential` but it looked like N-2 so that is what I stuck with and propagated out. - Without an aggressive sliding MSRV, we discourage people from using newer features because they will feel like they need permission which means it needs to be justified - Without an aggressive sliding MSRV, if the MSRV at one point in time works for someone, they tend to assume it will always work, leading to frustration at unmet expectations. I switched the MSRV check to `cargo check` from `cargo test` because I didn't want to deal with the out-of-diskspace issues and `check` will catch 99% of MSRV issues. Potential future improvements to `cargo-hack` - Allow `--version-range ..stable` so we can verify all MSRVs that aren't stable which would bypass the diskspace issues and allow us to more easily use `cargo test` again - Verify on a `cargo package` version of a crate (taiki-e/cargo-hack#216)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Packages can have two MSRVs
For example, if you use workspace inheritance, your local development / git dependency MSRV is 1.64 but your registry dependency MSRV could be lower but you can't verify it. This is because
cargo packageremoves these development-time features.We could verify the published version of a package if we did
cargo packageon each package and then verified the.cratefiles.The text was updated successfully, but these errors were encountered: