RFC: Rust SemVer 2

[Stargateur]

This RFC propose the Rust's SemVer 2 rules that define version requirement operator that can be used in Cargo to define the version of dependencies that Cargo can choose. The rules use SemVer 2.

Empirical change from Rust SemVer 1:

• Remove ranges >=, >, <=, <
• Remove logical "and" ,
• Add logical "or" ||
• Remove sugar 1.* or 1.0.*
• ~ behavior is now equivalent to ~1.0.*, ~1.* and ~*
• ^ will never consider a pre-release compatible with any other pre-release or release
• ~0 or 0.0 are not any more valid version requirement

Internal forum thread of the alpha RFC

Rendered

This work can be a base to another RFC about Version Requirement SemVer.

Related to https://github.com/rust-lang/rfcs/pull/3263

Plan to split this RFC:

• Make a RFC to add rust_semver field to cargo.
• Make a RFC to depreciate and add new features
• Rework this RFC as if other RFC have been accepted

TODO:

• work on depreciation instead of removal.
• considered use another character instead of reuse ~

[CAD97]

The RFC should probably explicitly provide an alternative for an in-place upgrade (i.e. without the rust-semver = "2" opt-in) and rationale for why the removals are justified, rather than clarifying their behavior. The RFC should also discuss the cost of having two incompatible versions of behavior, and why the benefit of the new behavior outweighs said cost.

Changes which could be applied to current version requirements:

• Clarifying ranges' interaction with pre-releases (given we define ^1.2.3 as >=1.2.3, <2.0.0, the intent is clearly to not include pre-releases in ranges that don't mention them)
• Deprecation of ranges
• Addition of ||, potentially &&, ()
• Deprecation of ,
• Redefinition of versions considered compatible within pre-releases[^1]
• Redefinition of how requirement operators work when pre-release versions are present[^1]
• crates-io banning publishing of new crates which do not follow more stringent rules (e.g. banning unbounded >= requirements or deprecated operators)

[^1]: Strictly speaking, this is a breaking change. However, due to the near universal agreement that "all pre-releases are compatible", the current behavior, is somewhere between useless and actively harmful, replacing the rules can be done in place.

Changes which require a breaking opt-in:

• Removal (rather than just deprecation) of ranges, ,, ~0, ^0, *
• Redefinition of ~ from "use specified MAJOR.MINOR" to "variable only in the last specified version segment"[^2]

[^2]: FWIW I personally think this is a better definition for ~ ignoring backwards compatibility and matching other ecosystems' behavior, but I also value backwards compatibility more.

(To reiterate the implicit point in the above: per my understanding of the RFC, the only motivation for making this a breaking change beyond depreciation of easily misusable operators is redefining ~.)

[Stargateur]

@CAD97

FWIW I personally think this is a better definition for ~ ignoring backwards compatibility and matching other ecosystems' behavior, but I also value backwards compatibility more.

I think I should have critic current ~ way more, actually, I miss understand what this operator was doing so much at first. The current behavior of ~ just don't have any logic, just 3 arbitrary rules.

Addition of ||, potentially &&, ()

Hard to say but I think I advice to never add () or && for a Rust SemVer 1.1, we add ||, make depreciation warning for everything removed in Rust SemVer 2. && would make no sense in my proposition, it will defeat the purpose to be simple and avoid user mistake of "raw" range.

Redefinition of versions considered compatible within pre-releases Redefinition of how requirement operators work when pre-release versions are present

I must really insist on https://github.com/semver/semver/pull/584#issuecomment-1125354556 warning about security concern to change rule without opt in.

FWIW I personally think this is a better definition for ~ ignoring backwards compatibility and matching other ecosystems' behavior, but I also value backwards compatibility more.

Well, that why I call it 2, ^^, I think we can have a tool to "upgrade" from Rust SemVer 1 to 2. But I'm not sure it's a good idea, users should read the new rules (thus these rules need to be explain with better words than mines in cargo documentation)

[joshtriplett]

We discussed this in today's @rust-lang/cargo meeting.

We felt like this RFC is trying to do too many things at once.

We'd like to see one RFC that just proposes removing things, but doesn't add anything new. We'd also like that RFC to tie it to edition, rather than adding a separate option; for instance if a project's Cargo.toml specifies edition = "2024", it can't use those removed things.

(Also, please don't call this "SemVer 2"; that's really confusing given that SemVer version 2 is a thing that exists and isn't related to this. Please call this something like "Removing some semver operators in a future edition".)

Separate from that, if we want to add new operators, we'd want those to be a separate proposal. And a sketch of that proposal should be discussed and roughly approved of before it becomes a full RFC.

@rfcbot close

[rfcbot]

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:

• [x] @Eh2406
• [x] @ehuss
• [x] @epage
• [x] @joshtriplett
• [x] @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This is now closed.