Add warning for using pre-release version in Cargo.toml

[linyihai]

Problem

As rust-lang/rfcs#3263 mentions and the cargo book says:

Cargo allows “newer” pre-releases to be used automatically. For example, if 1.0.0-beta is published, then a requirement foo = "1.0.0-alpha" will allow updating to the beta version. Note that this only works on the same release version, foo = "1.0.0-alpha" will not allow updating to foo = "1.0.1-alpha" or foo = "1.0.1-beta".

Cargo will also upgrade automatically to semver-compatible released versions from prereleases. The requirement foo = "1.0.0-alpha" will allow updating to foo = "1.0.0" as well as foo = "1.2.0".

It is necessary to notice user (especially new rust comer) that Cargo will upgrade the pre-release version, which is may be a breaking change.

Proposed Solution

When resolving the Cargo.toml, if there is any pre-release version present, warnning people that pre-release will automatically upgrade to new version, which may be a breaking change.

It's prefer to choose lint to generate the warning message.

Notes

originated from rust-lang/rfcs#3263 (comment)

[soloturn]

contrary to you i am new rust comer :) i am confused that it uses a different version as specified in toml. instead of printing a warning for a surprising behavior i would expect a viable fix is to use the version in the toml as every other build tool does, and offer a command to write newer version into toml. or do like javascript guys. package.json and package-lock.json.

[epage]

Our general policy towards warnings is to only emit them if there is a reasonable way to silence them. For everything else, we are waiting on cargo lints. For the unstable cargo lints, I see this being more clippy-like which we haven't figured out how we want to handle those.

For myself, I'm concerned with maintainers having to toggle operators back and forth as that can be error prone.

[ia0]

For more context, this effort is part of #2222 (and the issue was requested on zulip).

To be more precise on what the suggested lint is:

• It should trigger when a Cargo.toml contains a dependencies or build-dependencies (whether dev-dependencies is also concerned is to be decided) that references a pre-release with the default version requirement (i.e. no operator like ^ or =).
• The message should be to use an explicit version requirement in accord with the library documentation.
• The Cargo documentation could help library authors decide which particular version requirement to use (for example ^, =, or >=, <, to be decided, ideally describing the trade-offs between them).

The remaining action items would be:

• Figure out a way to silence the warning. A not user-friendly solution is to suggest in the warning message to silence it with an equivalent but explicit ^ (since that's the current default).
• Figure out if we also want to cover dev-dependencies. Said otherwise, how much do we care about breaking development? I guess we somehow do and should thus lint on all kinds of dependencies.
• Figure out if we want to help library authors design their pre-release version system. And if yes, what to suggest. My personal opinion would be something along the lines of having at least 2 pre-release number identifiers, one for breaking changes (akin major number) and one for the rest (akin minor and patch). For example x.y.z-a.b where b is bumped unless it's a breaking change in which case it's a (resetting b to zero).

For myself, I'm concerned with maintainers having to toggle operators back and forth as that can be error prone.

I don't understand to what this refers. Do you mean silencing the warning (i.e. prefixing ^) or do you mean when depending on a newer version (i.e. changing >=2.0.0-1.2, <2.0.0-2.0 to >=2.0.0-2.0, <2.0.0-3.0)? Both are indeed valid concerns. The question is whether this is worse than the current situation? At this point (i.e. until #2222 is fixed) we have to choose between bad and bad, there is no good. So the best we can do will still be bad, but as long as it's better on average (weighted by usage) it's still an improvement. The current situation is arbitrary build breakage. The proposed solution is arbitrary typos.