Open epage opened 4 weeks ago
Hi, thanks for the ping. So there is https://github.com/LukasKalbertodt/libtest-mimic/commit/08e76d3557ea7e4ebfac403574eeb6f5a17f49a4 from some time ago, where I removed the MSRV CI check since it broke due to a new clap
version. As you can see in the commit message, I don't really know how I, as a library maintainer, should deal with this. Do I simply state the MSRV of my code without dependencies? Do I state the MSRV of my code and of the oldest supported versions of my dependencies (which, in case of that commit, would be clap 4.0.x)? Because tracking the MSRV of the newest versions of all of my dependencies, that seems like exhausting and annoying work.
I suppose that Cargo can chose compatible dependency versions, also considering rust-version
. I'm not sure if that was already the case when I created that commit. I do know that CI just broke due to a new clap
version.
So yeah: can you tell me about best practices?
(Note: cargo hack
seems really cool, not only for MSRV. I didn't know that, thanks!)
While not yet on the stable version of the Cargo book, the Cargo team has posted guidance on MSRV that includes this topic, see https://doc.rust-lang.org/nightly/cargo/reference/rust-version.html#support-expectations
For myself, I have a Cargo.lock
committed that is compatible with my MSRV. You can jump start that on nightly using the MSRV-aware resolver, see https://doc.rust-lang.org/nightly/cargo/reference/config.html#resolverincompatible-rust-versions
To reproduce, I had to do:
Not seeing any MSRV verification in CI. Highly recommend
cargo hack
for this as it let's you single-source your MSRV, e.g. https://github.com/epage/_rust/blob/e121dd6ef9e11dfa818a813bbaffb12a16cd174e/.github/workflows/ci.yml#L54-L67