docs(ref): Mention x.y.* as a kind of version requirement to avoid. (#15310)

This expands the text introduced by #12323.

`x.y.*` is equivalent to `>=x.y.0, <x.(y+1).0`, so it can create an
unresolvable conflict in the same way as already discussed.

I also added a little punctuation to improve the structure of some
nearby sentences.

@rustbot label A-documenting-cargo-itself
This commit is contained in:
Weihang Lo 2025-03-14 05:00:37 +00:00 committed by GitHub
commit 44277a48be
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -163,18 +163,19 @@ is ignored and should not be used in version requirements.
>
> Avoid constraining the upper bound of a version to be anything less than the
> next semver incompatible version
> (e.g. avoid `">=2.0, <2.4"`) as other packages in the dependency tree may
> (e.g. avoid `">=2.0, <2.4"`, `"2.0.*"`, or `~2.0`),
> as other packages in the dependency tree may
> require a newer version, leading to an unresolvable error (see [#9029]).
> Consider whether controlling the version in your [`Cargo.lock`] would be more
> appropriate.
>
> In some instances this won't matter or the benefits might outweigh the cost, including:
> - When no one else depends on your package e.g. it only has a `[[bin]]`
> - When no one else depends on your package; e.g. it only has a `[[bin]]`
> - When depending on a pre-release package and wishing to avoid breaking
> changes then a fully specified `"=1.2.3-alpha.3"` might be warranted (see
> changes, then a fully specified `"=1.2.3-alpha.3"` might be warranted (see
> [#2222])
> - When a library re-exports a proc-macro but the proc-macro generates code that
> calls into the re-exporting library then a fully specified `=1.2.3` might be
> calls into the re-exporting library, then a fully specified `=1.2.3` might be
> warranted to ensure the proc-macro isn't newer than the re-exporting library
> and generating code that uses parts of the API that don't exist within the
> current version