Version requirements ^0 and ^0.0 behave unexpectedly

[CobaltCause]

Problem

Default requirements specify a minimum version with the ability to update to SemVer compatible versions. Versions are considered compatible if their left-most non-zero major/minor/patch component is the same. This is different from SemVer which considers all pre-1.0.0 packages to be incompatible.

— https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#default-requirements

Given this, it seems weird that ^0 is permitted because it's equivalent to >=0.0.0,<1.0.0 which accepts e.g. 0.1.0 and 0.2.0 despite being incompatible versions according to the second sentence of the quote. Similarly, ^0.0 is also permitted and accepts e.g. 0.0.1 and 0.0.2.

Steps

1. Add a dependency with the version requirements ^0 or ^0.0.
2. After the dependency makes a new breaking release without changing the number of leading zero components from what was chosen in step 1, run cargo update and expect to get a compatible release in your lockfile because you used the syntax for only selecting compatible releases.
3. Get an incompatible release instead.

Possible Solution(s)

In order of decreasing effectiveness for avoiding this problem:

1. Change Cargo's code to require default/caret requirements to contain at least one nonzero component if major, minor, and patch are not all zero (because that unambiguously requires the single version 0.0.0).
2. Same as above, but instead of a hard error, just emit a warning.
3. Change Cargo's documentation to strongly recommend against using ^0 and ^0.0.

Notes

No response

Version

cargo 1.89.0 (c24e10642 2025-06-23)
release: 1.89.0
commit-hash: c24e1064277fe51ab72011e2612e556ac56addf7
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
libgit2: 1.9.0 (sys:0.20.2 vendored)
libcurl: 8.12.1-DEV (sys:0.4.80+curl-8.12.1 vendored ssl:OpenSSL/3.5.0)
ssl: OpenSSL 3.5.0 8 Apr 2025
os: NixOS 25.11.0 [64-bit]

[epage]

For me, the question is where do we want to go with this long term, a lint (#12235) or a hard error. If a hard error, do we need any kind of transition (future-incompat warning, edition migration).

Note: some other proposed lints that may help with this:

• Lint on version requirements without a fully specified minimum bound #15577
• Lint that a version requirement is lower than what is currently in Cargo.lock #15583

[CobaltCause]

Personally I'd go for hard error, but 15577 would be sufficient for the lint route; I think 15583 is kind of orthogonal.

[weihanglo]

If being a hard error, do we bail out for only version requirements of direct dependencies, or all transitives? We did some hard deprefations in Edition 2024 #13629, but some we did it without Edition like source-less dependencies #13775. And that did cause some issues. I guess at least we should look at how many do we have in crates.io index to know the blast radius.