Fix msrv: Run msrv checks with minimal versions

[NobodyXu]

Since it is possible to for dependencies to bump MSRV in patch release, msrv checking should use the minimal versions supported by flate2.

Users cares deeply about msrv can also pin them to the minimal versions to maintain their current msrv.

This would have also help discover bugs in #424

[Byron]

Oh, right:

Run cargo build --features zlib-rs --no-default-features
 Downloading crates ...
  Downloaded libz-rs-sys v0.2.1
  Downloaded zlib-rs v0.2.1
error: package `zlib-rs v0.2.1` cannot be built because it requires rustc 1.75 or newer, while the currently active rustc version is 1.56.1

The MSRV is only valid for the C bindings, not for zlib-rs. Maybe this could also be clarified. For now, I think it's OK to remove zlib-rs from the set of tested deps, or add something separate with its own MSRV.

[NobodyXu]

Thanks removed it

[NobodyXu]

It can finally reproduce the error 🎉

[Byron]

Let me put my commit in and bump the crate version…

[jongiddy]

I disagree here. The rust-version causes users with earlier compiler version to see failures to download a recent version of flate2 that works for them. Users with version 1.56.1 can currently download the most recent version of flate2 and use it with the default features.

Increasing the rust-version will cause problems for them. Yes, they will have problems if they enable any of the other features. But they can deal with that by not using those features or upgrading their compiler.

[Byron]

Thanks for chiming in @jongiddy!

This makes sense and I have undone the change to the rust-version field, and updated the commit message accordingly.

@NobodyXu Could you provide another one of these PRs for the libz-sys crate? It seems it's unknowingly using features of more recent vcpkg versions.

[jongiddy]

To clarify some more, the problem with rust-version is that there are multiple things it could mean:

1. Any compiler version lower than rust-version will fail to build the flate2 code, probably due to flate2 use of a feature added to the compiler.
2. Any compiler version lower than rust-version will fail to build flate2 and its dependencies. This may be different depending on features (and their differing dependency sets) as well as over time as dependencies raise their minimal versions with a non-breaking version bump.
3. The compiler version that the maintainers are happy to support, generally known as the MSRV. This can be unrelated to compilability and also changes over time (e.g. flate2 has an MSRV policy that increases even if we make no changes to the code).

Essentially rust-version is not adequate for real MSRV handling and the only option above that really works is the first. At least with that option, the minimal version only changes when there is a commit to the flate2 repo.

If we raise the rust-version higher we will get complaints that users cannot get the newest version, even though it would work for them. I'd rather get complaints that a feature doesn't work with their old compiler than that they cannot use crates.io but can use GitHub main with their old compiler.

[Byron]

Thanks for the clarification, very insightful!

[jongiddy]

AIUI, what we are looking for here is to check that all features work when the MSRV (as defined by option 3 above) is used? I think that could exist as a separate task. The problem is that since the MSRV is current release - 1, then every 6 weeks we need to modify the workflow to update the compiler version.

It might work if we say the MSRV is 1.79 and then only update it when we feel like it, or when a dependency breaks CI.

[Byron]

Actually it's the smallest possible version that is still able to build the core features (i.e. without zlib-rs. In the README, it talks about the MSRV very conservatively, but I wouldn't be surprised if people were very upset if we'd all of the sudden stick to that minimal requirement only. Thus, previously, Rust 1.56 was tested and this PR adds a lot of detail which shows that it was already too low, while also showing that the Cargo.toml versions declared in dependencies aren't working everywhere either.

But you are absolutely right to ask under which circumstances this setup would break - in theory it does so only if this crate changes, as dependencies would be stuck at their minimal versions.

Maybe there should also be a forward-facing version of this task that tests with the latest dependencies - after all, these would be what truly can affect the typically possible MSRV.

I hope that makes some sense, and I am writing this thinking that I was probably missing some or all of your point :/.

[NobodyXu]

Could you provide another one of these PRs for the libz-sys crate? It seems it's unknowingly using features of more recent vcpkg versions.

@Byron Opened rust-lang/libz-sys#207

[jongiddy]

My main concern is that the rust-version should not be increased unnecessarily.

A user who happens to be stuck on Rust 1.56.1 can currently add flate2 = "1" to their dependencies and their code will build. Due to the current minimum version test, they will continue to receive working updates until the rust-version increases. When rust-version does eventually increase, Cargo should keep them on the last version that works with 1.56.1.

Now, if this user adds a backend feature, they will need cc and that increases the minimum versions that will work. But flate2 cannot control that. The next version of cc might reduce the supported compiler version! So flate2 should not specify that, but should let Cargo fail and tell the user which crate is the problem.

This change seems to be because users of flate2 see a message like error: package cc v1.0.99 cannot be built because it requires rustc 1.63 or newer when using specific features and you want that to change so that the direct dependency (flate2 or something higher) gets the blame. I don't think anything like that is practical right now. As you see, if you really want that, then the minimum version is 1.75 and can be increased at the whim of any dependency. Users need to learn to use cargo tree --invert to help identify the dependency hierarchy that is causing the problem.

[NobodyXu]

The next version of cc might reduce the supported compiler version!

Well that's impossible.

cc has a msrv of 1.63, same as debian.

The reason we keep 1.63 is because of complaints from users, otherwise we would bump to newer rustc already.

Previously we tried bumping it to 1.65/1.66c and gets pushed back, that's probably why you had experience of a reduction in msrv, it's actually a revert of msrv bump we did.

P.S. I'm co-maintainer of cc

[NobodyXu]

BTW for cc we really want to bump the msrv to drop some code and use some new features.

[jongiddy]

@NobodyXu Not suggesting that cc will do this. It was just an example that flate2 cannot control the evolution of minimum versions of its dependencies, so should not try to propagate the highest of their minimum versions as its minimum version, but instead let Cargo handle it.

[NobodyXu]

For the zlib-ng-cc part, I think cc is the only dependency?

In that case I suppose it's pretty easy to track.

so should not try to propagate the highest of their minimum versions as its minimum version, but instead let Cargo handle it.

I love the idea that cargo automatically selects one that fits in my msrv, but unfortunately they aren't ready yet.

[Byron]

Great, it works now!

@jongiddy Please note that only the tested MSRV was increased to 1.63, the claimed one is unchanged. Thus I would expect that there is no issue downstream.

[jongiddy]

@Byron We should keep the original minimum test as well, as we need to know when a PR uses a compiler feature that needs rust-version to be increased.

[Byron]

Strange, I am not seeing how this isn't covered particularly well now. But I agree, ideally nothing gets lost with these changes.

In any case, maybe you want to submit a PR for getting that test back and then I will probably see what I am missing right away.