Mention the need to define a reasonable MSRV

[estebank]

The guideline should make mention of defining a reasonable MSRV, how to go about doing so (explain how to install a specific Rust version using rustup and use it for buildling) and why (edition 2015 crates developed on a recent stable might inadvertently start using a recent API or backwards compatible feature).

Inspired by this conversation https://twitter.com/ekuber/status/1438867907388362757

[elichai]

Linking previous discussions: #123

[jjl]

i find cargo-msrv to be a pretty easy way to determine an MSRV

[BurntSushi]

If we were to add something like this, it should probably start with something like, "If you'd like to define an MSRV, then ..."

[kornelski]

I think users should be encouraged to specify cargo-readable MSRV when it lands:

rust-lang/rust#65262

Once this is used in Cargo to resolve dependencies (and it's doable even without Cargo's support via registry replacement feature), the problem will largely solve itself without burdening crate authors with supporting outdated Rust versions.

[Enet4]

(edition 2015 crates developed on a recent stable might inadvertently start using a recent API or backwards compatible feature)

This is something that had not occurred to me until now (in fact, I'm not sure if I understood the problem completely!), so it would be immensely important for this page to exist in the guidelines with an explanation of this phenomenon, perhaps even with examples.

With that said, I would be inclined to emphasize on the pros and cons of an MSRV, including a possible strategy for choosing when and how to embrace one.

[estebank]

I agree with what's been said. I think the important part is making sure that there's intent behind what the library author is doing and to have a reference on what can be done when they do desire to support old versions, as well as the reasons for doing and not doing them.

I also want to deal with the tooling side so that we can also help authors do what they want to do with intent, such as having warnings when publishing a new version that has a different implicit MSRV than what it was the previous time, and showing in crates.io that it is (like lib.rs does), but those are outside of the scope of providing documentation we can point people at (both authors and people either confused or angry with author's explicit policies).

[mattheww]

Concretely, I'd like to see advice provided for the following situation:

Suppose:

• I'm verifying that my library works with Rust 1.234, and intend to continue to do so at least until my next major version; and

• I believe that at present it works with some older versions, but I'm not testing that and don't plan to put any effort into keeping that the case.

Should I put rust-version = "1.234" in Cargo.toml or not?

It feels like I should, so as to document my intent, but (if I understand correctly) doing so would also make life less convenient for someone who has reason to use the library with Rust 1.233 right now and would prefer to delay dealing with with any future trouble that causes until it comes.

[ThomasdenH]

To be clear; if a dependency updates to use a newer compiler version in a minor update, that could break the minimum version policy without your crate even updating, correct? If so, then either

• You need to make sure that every dependency has a compatible MSRV policy. If any dependency can update the MSRV in a minor update, this is not an option.
• Or, you must fix the versions in the dependency specification, "1.2, <1.2.3". This is not good. For example, it means security patches require an update of all dependent crates in the dependency tree.

So, having a strict MSRV is only really possible in very select circumstances, namely when all dependencies have it. On the other hand, if you have it, you don't impose anything on dependent crates.

Maybe the advice should then be: Define a MSRV if

1. It is possible because all your dependencies define it, and
2. You're willing to handle the additional work associated with developing for and testing with older versions of the compiler.

[kornelski]

I think there's a value in specifying MSRV in Cargo.toml as a warning to users of old compiler — such explicit error is much better than a compilation error that makes rustc babble about nighty features and syntax errors.

It may have value someday when Cargo learns to use it for dependency resolution.

But apart from that I think maintaining MSRV more than 3 versions behind is a futile excercise.

Here's the MSRV data for all crates.io crates:

https://lib.rs/stats#rustc

• Crates that are compatible with old compilers are mainly because they're also old and abandoned.

• Crates that are actively maintained drop old compilers very quickly.

• Editions push MSRV up more than any other feature. I expect very soon Rust older than 1.56 will be unusable.

• Breakage is very "viral". Even if 99 out of 100 dependencies are compatible, the project is still broken.

• Almost all crate incompatibility is caused by dependencies. Few popular crates dictate MSRV for the entire ecosystem (e.g. zeroize for cryptography, and object for error handling crates).

[ThomasdenH]

Right, my comment assumed that the MSRV was actually a supported version, but it is a necessary requirement, but possibly not sufficient.

[KodrAus]

My own opinion on this is that if you don't have a lock file then you shouldn't be concerned with MSRVs. As far as real utility is concerned they're ceremonious at best. As a library author today you have no tools for managing a MSRV. Until that situation changes and there's real mechanisms for maintaining library toolchain compatibility that's in-line with Rust's release train model and can be applied consistently I don't think we should recommend any particular policy around MSRVs.

I don't think that's necessarily the same as deciding to pick and document a specific toolchain in your Cargo.toml and CI though.