rustc version support policy (MSRV)

[kquick]

What are the intentions for supporting versions of rustc (i.e. what version range is intended)? I'm asking because the CI here uses nixpkgs-unstable, but I have another project which includes yapall and builds against nixos-23.05, and the latter provides rustc 1.69.0. The latest dependabot changes caused updates that are no longer compatible with that version of rustc:

yapall> configuring
yapall> building
yapall> Executing cargoBuildHook
yapall> ++ env CC_x86_64-unknown-linux-gnu=/nix/store/7wkshj58fcsl1f3zyi67qsxgl1p8nki1-gcc-wrapper-12.2.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/7wkshj58fcsl1f3zyi67qsxgl1p8nki1-gcc-wrapper-12.2.0/bin/c++ CC_x86_64-unknown-linux-gnu=/nix/store/7wkshj58fcsl1f3zyi67qsxgl1p8nki1-gcc-wrapper-12.2.0/bin/cc CXX_x86_64-unknown-linux-gnu=/nix/store/7wkshj58fcsl1f3zyi67qsxgl1p8nki1-gcc-wrapper-12.2.0/bin/c++ cargo build -j 8 --target x86_64-unknown-linux-gnu --frozen --release
yapall> error: package `clap_derive v4.4.0` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.69.0
yapall> Either upgrade to rustc 1.70.0 or newer, or use
yapall> cargo update -p clap_derive@4.4.0 --precise ver
yapall> where `ver` is the latest version of `clap_derive` supporting rustc 1.69.0
error: builder for '/nix/store/q9wlw6i02ms08p57i9bapg5l9l8rzblh-yapall-0.0.0.drv' failed with exit code 101

For that project, I am not building other rust packages so I can update, but it would be good to be intentional about which versions of rustc are intended to be supported and ensure the CI validates that version range.

[langston-barrett]

Agreed that it would be good to make an intentional choice about this, thanks for raising the topic.

The status quo is that this project uses whatever version of Rust is installed on the ubuntu-latest CI runners. Currently, that's Rust 1.73. So the implicit support policy is just "whatever version of Rust ubuntu-latest uses". This is nice because:

• It's fast:

  • There's only one CI job (no matrix), so it consumes minimal resources ($)
  • The job uses a recent Rust toolchain, and rustc and Cargo generally get faster with each release
  • The job doesn't spend time installing Rust versions, they're baked into the image

• It's simple:

  • We can just merge Dependabot PRs as long as they pass CI, and they virtually always do
  • No matrix, no rustup, etc. in the workflow
  • No intervention is required to test against the latest compiler/OS versions

However, it has significant downsides as well:

• It's not reproducible: The version of Ubuntu and Rust can change at any time, breaking builds without any source changes
• It can change MSRV easily and without warning

The latter point is less of a big deal in the Rust ecosystem than in, say, the Haskell ecosystem, because the Rust language tends to change less in backwards-incompatible ways. However, as you note, this can still be an issue when consumers would like to use a version of rustc provided by a package manager.

I think we should adopt the minimally-burdensome policy (i.e., smallest range of Rust versions) that works for your project, as AFAIK it's the only one using yapall right now.