doc(yank): make versions have major parts

rust-lang · Mar 23, 2023 · 6b032af · 6b032af
1 parent 1ccbdae
commit 6b032af
Show file tree

Hide file tree

Showing 4 changed files with 92 additions and 92 deletions.
diff --git a/src/doc/man/cargo-yank.md b/src/doc/man/cargo-yank.md
@@ -27,26 +27,26 @@ current directory.
 
 ### How yank works
 
-For example, the `foo` crate published version `0.22.0` and another crate `bar`
-declared a dependency on version `foo = 0.22`. Now `foo` releases a new, but
-not semver compatible, version `0.23.0`, and finds a critical issue with `0.22.0`.
-If `0.22.0` is yanked, no new project or checkout without an existing lockfile will be
-able to use crate `bar` as it relies on `0.22`.
-
-In this case, the maintainers of `foo` should first publish a semver compatible version
-such as `0.22.1` prior to yanking `0.22.0` so that `bar` and all projects that depend
-on `bar` will continue to work.
-
-As another example, consider a crate `bar` with published versions `0.22.0`, `0.22.1`, 
-`0.22.2`, `0.23.0` and `0.24.0`. The following table identifies the versions
-cargo could use in the absence of a lockfile for different SemVer requirements,
-following a given release being yanked:
-
-| Yanked Version / SemVer requirement | `bar = "0.22.0"`                          | `bar = "=0.22.0"` | `bar = "0.23.0"` |
-|-------------------------------------|-------------------------------------------|-------------------|------------------|
-| `0.22.0`                            | Use either `0.22.1` or `0.22.2`           | **Return Error**  | Use `0.23.0`     |
-| `0.22.1`                            | Use either `0.22.0` or `0.22.2`           | Use `0.22.0`      | Use `0.23.0`     |
-| `0.23.0`                            | Use either `0.22.0`, `0.21.0` or `0.22.2` | Use `0.22.0`      | **Return Error** |
+For example, the `foo` crate published version `1.5.0` and another crate `bar`
+declared a dependency on version `foo = "1.5"`. Now `foo` releases a new, but
+not semver compatible, version `2.0.0`, and finds a critical issue with `1.5.0`.
+If `1.5.0` is yanked, no new project or checkout without an existing lockfile
+will be able to use crate `bar` as it relies on `1.5`.
+
+In this case, the maintainers of `foo` should first publish a semver compatible
+version such as `1.5.1` prior to yanking `1.5.0` so that `bar` and all projects
+that depend on `bar` will continue to work.
+
+As another example, consider a crate `bar` with published versions `1.5.0`,
+`1.5.1`, `1.5.2`, `2.0.0` and `3.0.0`. The following table identifies the
+versions cargo could use in the absence of a lockfile for different SemVer
+requirements, following a given release being yanked:
+
+| Yanked Version / SemVer requirement | `bar = "1.5.0"`                         | `bar = "=1.5.0"` | `bar = "2.0.0"`  |
+|-------------------------------------|-----------------------------------------|------------------|------------------|
+| `1.5.0`                             | Use either `1.5.1` or `1.5.2`           | **Return Error** | Use `2.0.0`      |
+| `1.5.1`                             | Use either `1.5.0` or `1.5.2`           | Use `1.5.0`      | Use `2.0.0`      |
+| `2.0.0`                             | Use either `1.5.0`, `1.5.1` or `0.22.2` | Use `1.5.0`      | **Return Error** |
 
 ### When to yank
 
@@ -58,8 +58,9 @@ typically a less disruptive mechanism to inform users and encourage them to
 upgrade, and avoids the possibility of significant downstream disruption
 irrespective of susceptibility to the vulnerability in question.
 
-A common workflow is to yank a crate having already published a semver compatible version,
-to reduce the probability of preventing dependent crates from compiling.
+A common workflow is to yank a crate having already published a semver
+compatible version, to reduce the probability of preventing dependent
+crates from compiling.
 
 ## OPTIONS
 

diff --git a/src/doc/man/generated_txt/cargo-yank.txt b/src/doc/man/generated_txt/cargo-yank.txt
@@ -24,34 +24,34 @@ DESCRIPTION
        the current directory.
 
    How yank works
-       For example, the foo crate published version 0.22.0 and another crate
-       bar declared a dependency on version foo = 0.22. Now foo releases a new,
-       but not semver compatible, version 0.23.0, and finds a critical issue
-       with 0.22.0. If 0.22.0 is yanked, no new project or checkout without an
-       existing lockfile will be able to use crate bar as it relies on 0.22.
+       For example, the foo crate published version 1.5.0 and another crate bar
+       declared a dependency on version foo = "1.5". Now foo releases a new,
+       but not semver compatible, version 2.0.0, and finds a critical issue
+       with 1.5.0. If 1.5.0 is yanked, no new project or checkout without an
+       existing lockfile will be able to use crate bar as it relies on 1.5.
 
        In this case, the maintainers of foo should first publish a semver
-       compatible version such as 0.22.1 prior to yanking 0.22.0 so that bar
-       and all projects that depend on bar will continue to work.
+       compatible version such as 1.5.1 prior to yanking 1.5.0 so that bar and
+       all projects that depend on bar will continue to work.
 
-       As another example, consider a crate bar with published versions 0.22.0,
-       0.22.1, 0.22.2, 0.23.0 and 0.24.0. The following table identifies the
+       As another example, consider a crate bar with published versions 1.5.0,
+       1.5.1, 1.5.2, 2.0.0 and 3.0.0. The following table identifies the
        versions cargo could use in the absence of a lockfile for different
        SemVer requirements, following a given release being yanked:
 
-       +-----------------------+-----------------------+-----------+----------+
-       | Yanked Version /      | bar = "0.22.0"        | bar =     | bar =    |
-       | SemVer requirement    |                       | "=0.22.0" | "0.23.0" |
-       +-----------------------+-----------------------+-----------+----------+
-       | 0.22.0                | Use either 0.22.1 or  | Return    | Use      |
-       |                       | 0.22.2                | Error     | 0.23.0   |
-       +-----------------------+-----------------------+-----------+----------+
-       | 0.22.1                | Use either 0.22.0 or  | Use       | Use      |
-       |                       | 0.22.2                | 0.22.0    | 0.23.0   |
-       +-----------------------+-----------------------+-----------+----------+
-       | 0.23.0                | Use either 0.22.0,    | Use       | Return   |
-       |                       | 0.21.0 or 0.22.2      | 0.22.0    | Error    |
-       +-----------------------+-----------------------+-----------+----------+
+       +------------------------+----------------------+----------+----------+
+       | Yanked Version /       | bar = "1.5.0"        | bar =    | bar =    |
+       | SemVer requirement     |                      | "=1.5.0" | "2.0.0"  |
+       +------------------------+----------------------+----------+----------+
+       | 1.5.0                  | Use either 1.5.1 or  | Return   | Use      |
+       |                        | 1.5.2                | Error    | 2.0.0    |
+       +------------------------+----------------------+----------+----------+
+       | 1.5.1                  | Use either 1.5.0 or  | Use      | Use      |
+       |                        | 1.5.2                | 1.5.0    | 2.0.0    |
+       +------------------------+----------------------+----------+----------+
+       | 2.0.0                  | Use either 1.5.0,    | Use      | Return   |
+       |                        | 1.5.1 or 0.22.2      | 1.5.0    | Error    |
+       +------------------------+----------------------+----------+----------+
 
    When to yank
        Crates should only be yanked in exceptional circumstances, for example,
@@ -169,4 +169,3 @@ EXAMPLES
 
 SEE ALSO
        cargo(1), cargo-login(1), cargo-publish(1)
-
diff --git a/src/doc/src/commands/cargo-yank.md b/src/doc/src/commands/cargo-yank.md
@@ -27,26 +27,26 @@ current directory.
 
 ### How yank works
 
-For example, the `foo` crate published version `0.22.0` and another crate `bar`
-declared a dependency on version `foo = 0.22`. Now `foo` releases a new, but
-not semver compatible, version `0.23.0`, and finds a critical issue with `0.22.0`.
-If `0.22.0` is yanked, no new project or checkout without an existing lockfile will be
-able to use crate `bar` as it relies on `0.22`.
-
-In this case, the maintainers of `foo` should first publish a semver compatible version
-such as `0.22.1` prior to yanking `0.22.0` so that `bar` and all projects that depend
-on `bar` will continue to work.
-
-As another example, consider a crate `bar` with published versions `0.22.0`, `0.22.1`, 
-`0.22.2`, `0.23.0` and `0.24.0`. The following table identifies the versions
-cargo could use in the absence of a lockfile for different SemVer requirements,
-following a given release being yanked:
-
-| Yanked Version / SemVer requirement | `bar = "0.22.0"`                          | `bar = "=0.22.0"` | `bar = "0.23.0"` |
-|-------------------------------------|-------------------------------------------|-------------------|------------------|
-| `0.22.0`                            | Use either `0.22.1` or `0.22.2`           | **Return Error**  | Use `0.23.0`     |
-| `0.22.1`                            | Use either `0.22.0` or `0.22.2`           | Use `0.22.0`      | Use `0.23.0`     |
-| `0.23.0`                            | Use either `0.22.0`, `0.21.0` or `0.22.2` | Use `0.22.0`      | **Return Error** |
+For example, the `foo` crate published version `1.5.0` and another crate `bar`
+declared a dependency on version `foo = "1.5"`. Now `foo` releases a new, but
+not semver compatible, version `2.0.0`, and finds a critical issue with `1.5.0`.
+If `1.5.0` is yanked, no new project or checkout without an existing lockfile
+will be able to use crate `bar` as it relies on `1.5`.
+
+In this case, the maintainers of `foo` should first publish a semver compatible
+version such as `1.5.1` prior to yanking `1.5.0` so that `bar` and all projects
+that depend on `bar` will continue to work.
+
+As another example, consider a crate `bar` with published versions `1.5.0`,
+`1.5.1`, `1.5.2`, `2.0.0` and `3.0.0`. The following table identifies the
+versions cargo could use in the absence of a lockfile for different SemVer
+requirements, following a given release being yanked:
+
+| Yanked Version / SemVer requirement | `bar = "1.5.0"`                         | `bar = "=1.5.0"` | `bar = "2.0.0"`  |
+|-------------------------------------|-----------------------------------------|------------------|------------------|
+| `1.5.0`                             | Use either `1.5.1` or `1.5.2`           | **Return Error** | Use `2.0.0`      |
+| `1.5.1`                             | Use either `1.5.0` or `1.5.2`           | Use `1.5.0`      | Use `2.0.0`      |
+| `2.0.0`                             | Use either `1.5.0`, `1.5.1` or `0.22.2` | Use `1.5.0`      | **Return Error** |
 
 ### When to yank
 

diff --git a/src/etc/man/cargo-yank.1 b/src/etc/man/cargo-yank.1
@@ -24,57 +24,57 @@ or using \fBcargo\-login\fR(1).
 If the crate name is not specified, it will use the package name from the
 current directory.
 .SS "How yank works"
-For example, the \fBfoo\fR crate published version \fB0.22.0\fR and another crate \fBbar\fR
-declared a dependency on version \fBfoo = 0.22\fR\&. Now \fBfoo\fR releases a new, but
-not semver compatible, version \fB0.23.0\fR, and finds a critical issue with \fB0.22.0\fR\&.
-If \fB0.22.0\fR is yanked, no new project or checkout without an existing lockfile will be
-able to use crate \fBbar\fR as it relies on \fB0.22\fR\&.
-.sp
-In this case, the maintainers of \fBfoo\fR should first publish a semver compatible version
-such as \fB0.22.1\fR prior to yanking \fB0.22.0\fR so that \fBbar\fR and all projects that depend
-on \fBbar\fR will continue to work.
-.sp
-As another example, consider a crate \fBbar\fR with published versions \fB0.22.0\fR, \fB0.22.1\fR, 
-\fB0.22.2\fR, \fB0.23.0\fR and \fB0.24.0\fR\&. The following table identifies the versions
-cargo could use in the absence of a lockfile for different SemVer requirements,
-following a given release being yanked:
+For example, the \fBfoo\fR crate published version \fB1.5.0\fR and another crate \fBbar\fR
+declared a dependency on version \fBfoo = "1.5"\fR\&. Now \fBfoo\fR releases a new, but
+not semver compatible, version \fB2.0.0\fR, and finds a critical issue with \fB1.5.0\fR\&.
+If \fB1.5.0\fR is yanked, no new project or checkout without an existing lockfile
+will be able to use crate \fBbar\fR as it relies on \fB1.5\fR\&.
+.sp
+In this case, the maintainers of \fBfoo\fR should first publish a semver compatible
+version such as \fB1.5.1\fR prior to yanking \fB1.5.0\fR so that \fBbar\fR and all projects
+that depend on \fBbar\fR will continue to work.
+.sp
+As another example, consider a crate \fBbar\fR with published versions \fB1.5.0\fR,
+\fB1.5.1\fR, \fB1.5.2\fR, \fB2.0.0\fR and \fB3.0.0\fR\&. The following table identifies the
+versions cargo could use in the absence of a lockfile for different SemVer
+requirements, following a given release being yanked:
 
 .TS
 allbox tab(:);
 lt lt lt lt.
 T{
 Yanked Version / SemVer requirement
 T}:T{
-\fBbar = "0.22.0"\fR
+\fBbar = "1.5.0"\fR
 T}:T{
-\fBbar = "=0.22.0"\fR
+\fBbar = "=1.5.0"\fR
 T}:T{
-\fBbar = "0.23.0"\fR
+\fBbar = "2.0.0"\fR
 T}
 T{
-\fB0.22.0\fR
+\fB1.5.0\fR
 T}:T{
-Use either \fB0.22.1\fR or \fB0.22.2\fR
+Use either \fB1.5.1\fR or \fB1.5.2\fR
 T}:T{
 \fBReturn Error\fR
 T}:T{
-Use \fB0.23.0\fR
+Use \fB2.0.0\fR
 T}
 T{
-\fB0.22.1\fR
+\fB1.5.1\fR
 T}:T{
-Use either \fB0.22.0\fR or \fB0.22.2\fR
+Use either \fB1.5.0\fR or \fB1.5.2\fR
 T}:T{
-Use \fB0.22.0\fR
+Use \fB1.5.0\fR
 T}:T{
-Use \fB0.23.0\fR
+Use \fB2.0.0\fR
 T}
 T{
-\fB0.23.0\fR
+\fB2.0.0\fR
 T}:T{
-Use either \fB0.22.0\fR, \fB0.21.0\fR or \fB0.22.2\fR
+Use either \fB1.5.0\fR, \fB1.5.1\fR or \fB0.22.2\fR
 T}:T{
-Use \fB0.22.0\fR
+Use \fB1.5.0\fR
 T}:T{
 \fBReturn Error\fR
 T}