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

[mathstuf]

How can a minimum be a range though? How is a minimum of >= 1.34.0 meaningfully different than just saying 1.34.0 is my minimum? What use case is enabled by that?

[distransient]

I suggested semver defaulting to a >= operator. This means that ">= 1.34.0" and "1.34.0" would be identical values, just like how in dependencies, which default to the caret operator, "^1.34.0" and "1.34.0" are identical values. The original functionality of the proposal would be identical with the caveat of some extra flexibility and code reuse. Personally I'm against the "minimum" name and think just the key "rust" or "rustc" is fine.

[Majkl578]

@distransient By definition semver-compliant constraint can't default to >= because it would allow next major version(s), breaking the semver guarantee.
But given that Rust itself isn't following semver I'm not sure it matters.

[Lokathor]

Rust attempts to, but there are clearly spelled out parts where it is not followed perfectly.

[steveklabnik]

(this is not correct; ranges are not defined in the spec at all. rust follows the entire semver spec accurately, but there are some extensions to the spec (like ranges) that different implementations disagree on. (I maintain both semver the spec as well as semver the rust package.))

…

On Fri, Dec 13, 2019 at 1:45 PM Lokathor ***@***.***> wrote: Rust attempts to, but there are clearly spelled out parts where it is not followed perfectly. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#65262?email_source=notifications&email_token=AAAGZCQDKNE5AWRQO2DV7HTQYPQ7JA5CNFSM4I7IF7Q2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG3BYIQ#issuecomment-565582882>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGZCRF4P2XHICGQJUFXOTQYPQ7JANCNFSM4I7IF7QQ> .

[Lokathor]

That is correct, but I wasn't talking about ranges, I was referring to Rust's policy of accepted breakage.

[joshtriplett]

Given that we're extremely unlikely to ever have a rust 2.x.y semver, I would propose that we use ~ by default to match the default for dependencies.

[Lokathor]

Cargo uses ^ by default according to the cargo book. That's a lot more appropriate to what we want. If you specify you need rust 1.36, then 1.37 will do just fine as well.

[steveklabnik]

@Lokathor the semver spec also says that projects define what “breakage” is.

That said, yes, ^ is a good default.

[ehuss]

Yep, sorry again about the delay. The team did talk about it in our last meeting and we felt like rust-version hit the right balance between the alternatives. Our meetings have been pretty full so it takes a while to get through things.

[djc]

Cool, thanks, I'll see if I can shake loose some testing efforts.

[djc]

Wrote up a call for testing here:

https://users.rust-lang.org/t/call-for-testing-unstable-cargo-support-for-rust-version/59386

If anyone here has other suggestions for what kinds of things to test, please suggest them there.

[joshtriplett]

This is on track to be stabilized in 1.56.

[newpavlov]

@joshtriplett
Great! What about the proposed MSRV-dependent dependency version resolution? Should we open a separate Rust or Cargo issue?

[joshtriplett]

@newpavlov That was moved to future work because, among other things, it would need some confirmation that the proposed approach to resolution is something we'd want to do. Given such confirmation, someone would then need to submit a PR implementing it.

[ehuss]

Sorry, forgot that there was a second tracking issue. Closing as this has been stabilized in rust-lang/cargo#9732.

[newpavlov]

I went ahead and created a separate issue for MSRV-dependent dependency version resolution: #89136

[peter-lyons-kehl]

To save people's time: As per https://doc.rust-lang.org/nightly/cargo/reference/manifest.html#the-rust-version-field, the field is called rust-version.