Tracking issue for RFC 2495, "Minimum Supported Rust Version"

[Centril]

This is a tracking issue for the RFC "Minimum Supported Rust Version" (rust-lang/rfcs#2495).

Note: There is a separate tracking issue on the Cargo side at: rust-lang/cargo#8072

Documentation: https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field

Steps:

• Implement the RFC (cc @rust-lang/cargo -- can anyone write up mentoring
  instructions?)
• Adjust documentation (see instructions on rustc-guide)
• Stabilization PR (see instructions on rustc-guide)

Unresolved questions:

• Name bike-shedding: rust vs rustc vs min-rust-version
• Additional checks?
• Better description of versions resolution algorithm.
• How nightly versions will work with "cfg based MSRV"?

[jhpratt]

My personal opinions:

Name → min-rust-version or msrv. The latter may have already been declined, but if accompanied by documentation it's certainly already relatively widespread.

Nightly — Both the dated version (2019-10-10) and the semver version (1.40.0 for when 1.38.0 is stable). The latter could be somewhat confusing, as I've never seen nightly referred to like that in practice. I no longer believe this is the best case. Using 2019-10-10 or nightly-2019-10-10 would be preferred.

[Majkl578]

Name bike-shedding: rust vs rustc vs min-rust-version

My personal preference would be rust-version. min-rust-version is a bit too long and msrv is a bit cryptic abbreviation for newcomers (when I first saw it I was like what Microsoft stuff is this referring to).

Regarding nightly versions: I do not like the suggestion by @jhpratt to use semver version for nightly (e.g. 1.40.0) because the constraint is too wide. I think using nightly-2019-10-10 (meaning nightly from 2019-10-10 or newer) would be better and specific enough.
Cargo then needs to be able to resolve what real semver version this refers to and when e.g. 2019-10-10 means 1.40.0 then stable 1.41.0 would be valid too.

[mathstuf]

Agreed with @Majkl578 about the nightly via semver thing. Just because nightly has your feature today doesn't mean it will appear in the stable release with that version number.

[distransient]

I went through the discussions and I couldn't see anyone discussing representing the version as a semver version requirement like package dependencies, only instead defaulting to a >= xxx comparison operator when none is present instead of a caret operator. This would be useful personally, preserves the already proposed functionality, and seems like it'd reuse existing code. This leaves the nightly question open, however. Which perhaps would have to be a special case over all of that? 😅

[Lokathor]

Minimum rust version should absolutely be a semver comparison, yes.

[distransient]

I read the RFC a second time and saw a part suggesting semver comparison but I'm leaving my comment to keep the use-case clearly vocalized

[newpavlov]

the use-case clearly vocalized

What is this use-case though? In your previous post you only said it would be useful for you personally, without specifying why exactly. In the RFC I've wrote:

value should be a version in semver format without range operators.

exactly because I didn't see why it would be useful outside of the nightly extension, and even with the extension I am not 100% sure this feature would pull its weight. Also IIRC during discussion no one have brought any substantial arguments for supporting range operators with "1.X" versions.

[distransient]

Targeting a specific Rust ABI would require pinning the Rustc version to an exact number. This can easily be accomplished with semver without developing an entirely new syntax