Closed
Description
It seems the just-released v1.0.106 bumped the MSRV from 1.63 to 1.67 in a patch release.
Unfortunately this breaks our downstream MSRV builds, which depend on rustc 1.63 (currently shipped with Debian Bookworm).
I want to ask you to consider reverting the MSRV bump as it introduces issues for users downstream that need to support 'older' Rust version, especially since raising the MSRV seems to have happened only for a mere convenience feature in #1137
Metadata
Metadata
Assignees
Labels
No labels
Activity
NobodyXu commentedon Jul 8, 2024
Hello, sorry to hear that it breaks your build.
Is it possible for you to pin the cc version via
Cargo.lock
?BTW cargo is working on a msrv-aware resolution feature to help this.
TheBlueMatt commentedon Jul 8, 2024
For a library to support an MSRV, sadly, that's not an option. We could pin cc explicitly in the Cargo.toml, but that really sucks as it means any new features needed for new platforms cant work either.
There's also the issue of -Zbuild-std, which doesn't support Cargo.lock and is needed when building targeting apple platforms from Linux (which is, in turn, needed for practical reproducible builds, or at least I've never gotten them to work otherwise).
ChrisDenton commentedon Jul 8, 2024
I don't think it's currently tenable for us to consistently maintain a 3+ year MSRV.
If using the Debian system rustc is absolutely necessary, note that they do also maintain a cc-rs package for this purpose.
NobodyXu commentedon Jul 8, 2024
stdlib/rustc doesn't pin the version?
I was under the impression that stdlib/rustc pin to a specific cc version...
But if you are using
-Zbuild-version
, then it should be nightly compiler, unless you compiled the rustc with some special options to enable nightly optionsTheBlueMatt commentedon Jul 8, 2024
I mean that may well be the case, but (a) we could at least only change the MSRV if there's a compelling feature that cannot (practically) be shipped without changing the MSRV, and/or (b) change the minor (or major) version when that point is reached. At this point it seems like
cc
did just fine with a very old MSRV for a long time and until now hadn't found a feature that was work increasing it for even with a very low bar for doing so. Bumping that bar a bit would be much appreciated.Sadly -Zbuild-std doesn't (to my knowledge) currently pin crate versions and pulls them from crates.io. Its a known limitation, AFAIU.
NobodyXu commentedon Jul 8, 2024
If it is for x-lto, is there another way?
I.e. compile in docker, where the rustc 1.67 and clang uses the same LLVM version?
ChrisDenton commentedon Jul 8, 2024
Others have tried this approach (treating it as a semver breaking change) but found it isn't really tenable. E.g. see the discussion on the API guidelines repo rust-lang/api-guidelines#231 (comment)
TheBlueMatt commentedon Jul 8, 2024
Major version maybe not but many other projects have no problem changing the minor version for MSRV changes? eg tokio does it and it lets tokio support the MSRV-limited versions for some time with security and important updates without being forced into a low MSRV forever.
I mean in principle yes, but that takes building an application from source from "just clone this repo, install rust and build" to "first build rust, including fetching a full version of docker or whatever, also build llvm and clang from source, etc", which is totally untenable.
NobodyXu commentedon Jul 8, 2024
I'm ok with a 1.1.0 release, that sounds very reasonable
NobodyXu commentedon Jul 8, 2024
Yeah that makes sense, for project that needs x-lto, I guess either you depend on debian stable, or maintain a
Dockerfile
officially with the samellvm
versionNoratrieb commentedon Jul 8, 2024
How does updating it in a minor release vs a patch release help you? I don't see a significant difference there.
TheBlueMatt commentedon Jul 8, 2024
Its not a huge difference, no, either way we're stuck pinning cc in
Cargo.toml
explicitly which sucks, the only difference is assumingcc
takes a stance liketokio
where it can/does backport security and important bugfixes (or, forcc
, possibly even new platform support where it doesn't require breaking MSRV for existing platforms) to the prior minor version. Of course my preferred outcome would be at least a policy of "dont bump MSRV unless you kinda have to", but I was just raising other options.10 remaining items