Contradictory MSRV

[arnodb]

Hi, I read in the main README.md:

This crate currently has an MSRV of Rust 1.63. Increasing the MSRV is considered a breaking change and thus requires a major version bump.

And I started getting this recently (when home decided to bump their MSRV):

$ cargo build
error: package `home v0.5.9` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.68.2
Either upgrade to rustc 1.70.0 or newer, or use
cargo update -p home@0.5.9 --precise ver
where `ver` is the latest version of `home` supporting rustc 1.68.2

I already saw a couple of MSRV debates in some other repositories. I don't have an opinion yet on the matter. However, README.md is now wrong de facto.

Now on opinions, at least I think 1.70.0 as MSRV for a crate such as home is slightly radical but I don't know what motivated this sudden change.

I had to use a < in my Cargo.toml, which apparently has been a huge controversy in bincode a couple of years ago. Anyway, this is not in the scope of which, but which is impacted by it because an external dependency broke the official MSRV.

[Xaeroxe]

We can't meaningfully control or guarantee the MSRV set by our dependencies unless we pin all of our dependencies. If the ecosystem as a whole does this, then crate developers will find that people aren't downloading their patch updates. Patch updates are an important part of how the ecosystem responds to critical bugs and security flaws. So it is my opinion that this sort of problem ought to be solved by the end user. If you require a specific version of home, then you should add that version to your own Cargo.toml using one of the alternate syntaxes for version specification. To solve this specific scenario, you should pin version 0.5.5

I'm open to discussion on this, but that is my initial impression of this situation.

[arnodb]

To solve this specific scenario, you should pin version 0.5.5

This is exactly what I did. However, as you mentioned, that blocks security updates. I am considering reverting this change for that reason. That means MSRV, at best, indicates it is "possible" to make the crate compile but not necessarily with the default behaviour of Cargo which, in the absence of a lock file, will pick the latest available version of the dependencies.

Two problems remain:

• The advertised MSRV (e.g. in your README.md) may look incorrect, the discussion shows that it depends on the point of view.
• Ideally the advertised MSRV should be tested by CI. Question is how? The only answer I see, if the dependency is not pinned in Cargo.toml, is to pin the dependency in CI when testing MSRV.

Alternatively, nothing should be done, and MSRV should be considered only as an unverified claim. I am not entirely comfortable with this though.

Side note: implementing the suggestion about CI could help refining README.md in the sense that it does the minimum pinning to make the crate compile with MSRV.

[Xaeroxe]

Version 6.0.0 bumped the MSRV to 1.70. The README was updated accordingly, along with a notice that relaxed the portrayal of how strong the MSRV is. MSRV has been tested by CI for quite some time, however this won't catch upstream MSRV changes that were made after the PR was merged. That is how the original issue was able to occur.

[Xaeroxe]

I gave cargo's MSRV aware resolver a spin with which 5.0.0 and it seems to be working great. If you want to get in on this ahead of time you can use the command provided in this issue to generate a compatible lock file rust-lang/cargo#13873