[Pre-Pre-RFC] Reviving minimum Rust version (published as RFC 2495)

[naicode]

@newpavlov

Which might not be a good idea, i.e. newer versions, especially patch versions might have closed security vulnerabilities or fixed other bugs

I don’t think that this is a problem about rust field and tooling around it, but about authors responsibility and desire to backport such patches. Described functionality allows to do it, e.g. for pre-1.0 crates authors can publish 0.1.10 with backported updates and rust="1.30" , and immideatly after 0.1.11 update for the main branch with rust="1.45" . (it stretches semver quite a bit, but AFAIK unfortunately we can’t use something like 0.1.3.1 for backports) And for post-1.0 crates convention can be to bump minor version on MSRV change (so it’s not a breaking update) to allow publishing backports by bumping patch version.

I agree

@newpavlov

If authors knows MSRV they’ll provide rust field explicitly. As I see it rust="stable" will not bring anything new to the table here.

I don't thing so, if I start a new crate I wouldn't bother to pin to any rust version before it being halfway stable. But I would ping the channel I'm targeting. Still I might not always use the same compiler as the channel I'm targeting e.g. I might use nightly for some better debug info (e.g. external-macro-backtrace). So it would be rely nice if I could just state that this works on "stable"/"nightly"/"beta". Even better if I e.g. accidentally run cargo publish with a nightly cargo on a rust=stable crate the compiler could tell me that I'm doing stupid thinks.

In context of this discussion I would consider:

• rust="stable"/"beta" states that it's meant for stable but not jet committed to any min. version through cargo publish can turn the "stable" into the local used stable rustc version
• and as this is not meant to be for stableish crates we could warn on cargo package if a crate with a version > 1.0.0 has no rust version flag or uses rust="stable"/"beta"

[newpavlov]

Hm, so if I understood you correctly rust="stable" will be essentially just a failsafe, and exact Rust version number will be still implicitly inserted by cargo using current (stable) toolchain installed on user’s machine, but you will not be able to cargo publish such crate using nightly toolchain? Having such failsafe could be nice (though, I feel that rust="beta" is redundant, as ideally all previous “stable” crates should work on “beta”), but the big drawback will be that rust field will become required, so such change will be more disruptive (though it should help will teaching).

I am interested in that others think about it.

[newpavlov]

I’ve updated the RFC draft with changes based on the discussion. One of the additions is “cfg based MSRV” extension, which will allow us to formally specify how MSRV depends on features and target, e.g. like this (details can be changed):

rust = "1.30"
rust-cases = [
    { cfg = "x86_64-pc-windows-gnu", version = "1.35" },
    { cfg = 'cfg(feature = "foo")', version = "1.33" },
]

I will submit PR in the following 2-3 days if there is no additionall changes.

[ExpHP]

Can you clarify how this compares to previous proposals, and why this one has a better chance?

[newpavlov]

IIUC previous proposals got derailed by cargo schema versioning discussions. We do not need such functionality anymore, as currently cargo accepts unknown fields and issues only a warning for them. Plus I believe that the current proposal is better thought-out than the previous ones and additionally it includes direction for further refinement of MSRV functionality.

[newpavlov]

The proposal is published as RFC 2945!