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

[newpavlov]

I feel like the RFC will eventually need to include why Editions are not sufficient

As I see it two main reasons are:

• Dependency on features introduced after edition release (e.g. it’s not enough to say edition="2018" for crate which uses Rust 1.35 feature)
• In my understanding of editions functionality, only small portion of new features will require migration to a new edition. For example if ARM intrinsics get stabilized in Rust 1.40 you will be able to use them in edition="2015" crate, thus the legality of rust="1.40" and edition="2015" combination.

In general MSRV and Edition have different roles.

I guess it is safe to assume that this feature will be implemented together of after Rust 2018 release, so it’s mostly “for the future”.

The best you can get is that edition implies the latest rustc version before the next Edition.

Maybe you wanted to say “oldest version of the current Edition”? If yes, then I’ve meant that edition=N in the absence of explicit rust field implies that it equals to an oldest Rust version of the specified edition.

If crate does not specify edition and rust the only valid approach to allow things work as they do now is to interpret it as edition="2015" and rust="1.0" (so essentially no restrictions will be applied to versions resolution), so this part of the RFC is mostly about backward compatability.

Unfortunately there is no safe way to specify rust="1.20", as Rust 1.20 will not be able to parse Cargo.toml with rust field. (though I’ll need to check if it’s indeed the case)

[epage]

The best you can get is that edition implies the latest rustc version before the next Edition.

Maybe you wanted to say “oldest version of the current Edition”? If yes, then I’ve meant that edition=N in the absence of explicit rust field implies that it equals to an oldest Rust version of the specified edition.

Actually, I meant what I said. As I point out, people might be using newer features from an edition and during the transition to this feature, this feature will misguess the rustc version. So the safest option is to choose the most recent rustc version possible.

If crate does not specify edition and rust the only valid approach to allow things work as they do now is to interpret it as edition=“2015” and rust=“1.0” (so essentially no restrictions will be applied to versions resolution), so this part of the RFC is mostly about backward compatability.

(emphasis added)

Is there a special cases I missed where “1.0” to mean “*”?

[newpavlov]

So the safest option is to choose the most recent rustc version possible.

But it will not be “the latest rustc version before the next Edition”, as you can use new features by being on the previous edition. So essentially you proposal boils down to “if crate does not specify rust field it is equal to the current stable version of Rust”, which I think will be overly-conservative approach. Do not forget that rust field does not guarantee anything, it’s just a “best effort” tool which relies on crate authors to work properly.

I believe the better approach will be to do the following: if rust field is not specified, cargo publish will automatically insert version of the currently used toolchain without modifying local Cargo.toml file. (i.e. Cargo.toml which will be sent to crates.io will have automatically generated rust field)

Is there a special cases I missed where “1.0” to mean “*”?

I don’t think so. I believe assumption about using only post-1.0 Rust is a safe one.

[epage]

But it will not be “the latest rustc version before the next Edition”, as you can use new features by being on the previous edition. So essentially you proposal boils down to “if crate does not specify rust field it is equal to the current stable version of Rust”, which I think will be overly-conservative approach. Do not forget that rust field does not guarantee anything, it’s just a “best effort” tool which relies on crate authors to work properly.

Like I said, I hadn’t looked into new features being available in old Editions and my proposal breaks down in that case.

I believe the better approach will be to do the following: if rust field is not specified, cargo publish will automatically insert version of the currently used toolchain without modifying local Cargo.toml file. (i.e. Cargo.toml which will be sent to crates.io will have automatically generated rust field)

This seems like a nice compromise.

[Eh2406]

Not speaking to any broader discussion of whether we should do this, but as the person most likely to have to implement it, I do not foresee this being hard to implement in cargo’s resolver. One way is we can just filter the result from querying the index to crates with msrv < our msrv. The tricky part would be, as usual, the error messages, but even that is doable.

[naicode]

I think another aspect to consider is that not all crates will have a fixed minimal rustc/cargo version. Especially if a crate if fairly new an still in flux (and might stay in this state for a while) it totally makes sense to only commit just to an release channel or a version relative to one.

So I would do something like:

• "X.Y" (e.g. "1.23") for having a minimal version
• "stable","beta" for the last release in stable, beta at any time
• "stable-1" (and smimilar) like “stable” but with a slack period of 1 release cycle (not sure if we need it, but having e.g. "stable-0.5" which says that it works with only with the newest stable release but gives you 3week time to upgrade seems not wrong)
• "nightly" for the latest nightly snapshot at any time
• "nightly: ..." se the first post in this thread

Also there are a lot of versioning related problems for which there isn’t a single good answer e.g. if bumping the minimal version is a breaking change. So we should avoid to enforce to many checks.

Additionally sometimes people aren’t aware that there crate works on earlier versions, especially if this is only true wrt. to some features not being enabled or some target arch, so we might want to add a way to disable the version error or by default only make it a warning.

Lastly the minimal version sometimes depends on the target arch, os and enabled features which can not be expressed through a simple rust version field.

Still I think having a simple rust version field (including “nightly” and “stable” as versions) which is checked but not necessarily enforced seems like an good idea.

[newpavlov]

I don’t think that having “stable”, “beta” and “nightly” mean the latest Rust version on the respective channel is a good idea. For example it will look quite strange for a crate published an year ago to require latest stable. i think for new crates aproach described earlier with using current toolchain version when publishing crate should solve your concerns.

I agree that option to disable MSRV checks for dependencies will be a good escape hatch and it will work nicely with the automatic rust selection. As for publishing crates we already have --no-verify option.

[naicode]

This is why a check minimal version is tricky, some crates will officially only support latest stable/beta/nightly and checking for this makes sense when using them through git,path dependencies. But if they publish a specific version of a crate this version is innmutable and through this implicitly compatible with the currently actual rust version and all newer ones (except maybe for nightly crates in some cases).

Maybe the cargo package command could check what “stable”/“beta” is at the point of packaging* and add this meta information to the package (which then is uploaded to cargo).

*(local on the system of the person doing the packagine i.e. in worst cast this would be the rust version used for packaging)

[naicode]

The point of having “stable” as a version is:

• using a specific version number can be (miss-)interpreted as committing to a specific version
• some would argue that changing the min. version is a braking change or at last requires bumping the minor version number
• but if you develop a crate against only the newest version of stable (e.g. because it’s still in flux) then adding a patch might implicitly bump the min. version by you using a new feature, even through it might be internally only

(Without question having a explicit min. version for any half stable crate is recommended, but crates are published even before they reach this point)

[Ixrec]

I think it makes sense to declare that you support a channel, and have cargo translate that into a specific rustc version every time you publish. Then we’d recommend that you only declare a specific rustc version if you actually have a CI job running against that specific version, and everyone else defaults to whatever version they had installed when they ran cargo publish. That way every published version of a crate would have a single immutable minimum rustc version associated with it, and that version is about as likely to be the “true” minimum version as I think we can realistically hope to achieve here.

[newpavlov]

using a specific version number can be (miss-)interpreted as committing to a specific version

If rust is provided manually then author commits to supporting the selected version. if rust field is not provided (i.e. cargo uses current toolchain version each time crate is published), then automatically generated rust will mean “crate was build using this Rust version”, it may work on older versions, but you’ll have to test it. So crate author will implicitly commit to the version just by using it to develop the crate. Note that in the local Cargo.toml rust field still will not be present, so if author has updated toolchain, on the next cargo publish the new version for rust field will be selected.

some would argue that changing the min. version is a braking change or at last requires bumping the minor version number

I really hope that introduction of rust field will close this debate. With it bumping MSRV will not be a breaking change, as older compiler will simply select older crate version which support it.

but if you develop a crate against only the newest version of stable (e.g. because it’s still in flux) then adding a patch might implicitly bump the min. version by you using a new feature, even through it might be internally only

I think you misunderstood how automatic selection will work. Local Cargo.toml will not contain automatically selected rust field, it will be just implictly added on cargo publish. (with an appropriate warning) So if you develop crate and update toolchain on each cargo publish wll be selected your current toolchain version.

[Dylan-DPC]

• "X.Y" (e.g. "1.23" ) for having a minimal version
• "stable" , "beta" for the last release in stable, beta at any time
• "stable-1" (and smimilar) like “stable” but with a slack period of 1 release cycle (not sure if we need it, but having e.g. "stable-0.5" which says that it works with only with the newest stable release but gives you 3week time to upgrade seems not wrong)
• "nightly" for the latest nightly snapshot at any time
• "nightly: ..." se the first post in this thread

For stable-n, How would one know when the “stable” was set?

I would prefer a simple minimum-version key in the Cargo.toml. For nightly/beta the user could either specify nightly or <version>-nightly.

[newpavlov]

Hm, the only advantage which I can see is that it will allow to develop on Nightly, but cargo will select latest stable version known to it. Though I am not sure if it’s a good aproach, as I don’t think that we can assume that Nightly compiler will have the same behaviour as stable even if crate does not enable nightly features. Can you please argument a bit more why this apporach is preferable to “if rust is not provided, cargo publish will use current (local) toolchain version”?

[naicode]

If rust is provided manually then author commits to supporting the selected version. if rust field is not provided (i.e. cargo uses current toolchain version each time crate is published), then automatically generated rust will mean “crate was build using this Rust version”, it may work on older versions, but you’ll have to test it.

But this misses which tool-chain the author made the crate for. Not having a filed should only be interpreted as not knowing if the author commited to any channel/version which isn’t the same as a author committing to only support the newest version.

I really hope that introduction of rust field will close this debate. With it bumping MSRV will not be a breaking change, as older compiler will simply select older crate version which support it.

Which might not be a good idea, i.e. newer versions, especially patch versions might have closed security vulnerabilities or fixed other bugs, forgetting to upgrade rust might therefore lead to implicitly introducing already fixed security vulnerabilities in your system.

[newpavlov]

But this misses which tool-chain the author made the crate for.

At the very least author made the crate for the toolchain which he uses (usuaully it will be latest stable or nigthly) and unfortunately it’s the only reliable information which we’ll have. 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.

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.

[naicode]

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

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.