doc(yank): when to yank

Author: weihanglo

src/doc/man/cargo-yank.md

@@ -50,18 +50,19 @@ requirements, following a given release being yanked:
 
 ### When to yank
 
-Crates should only be yanked in exceptional circumstances, for example,
-license/copyright issues, accidental inclusion of
-[PII](https://en.wikipedia.org/wiki/Personal_data), credentials, etc...
-In the case of security vulnerabilities, [RustSec](https://rustsec.org/) is
-typically a less disruptive mechanism to inform users and encourage them to
-upgrade, and avoids the possibility of significant downstream disruption
+Crates should only be yanked in exceptional circumstances, for example, an
+accidental publish, an unintentional SemVer breakages, or a significantly
+broken and unusable crate. In the case of security vulnerabilities, [RustSec]
+is 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.
 
+[RustSec]: https://rustsec.org/
+
 ## OPTIONS
 
 ### Yank Options

src/doc/man/generated_txt/cargo-yank.txt

@@ -55,13 +55,12 @@ DESCRIPTION
 
    When to yank
        Crates should only be yanked in exceptional circumstances, for example,
-       license/copyright issues, accidental inclusion of PII
-       <https://en.wikipedia.org/wiki/Personal_data>, credentials, etc… In
-       the case of security vulnerabilities, RustSec <https://rustsec.org/> is
-       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.
+       an accidental publish, an unintentional SemVer breakages, or a
+       significantly broken and unusable crate. In the case of security
+       vulnerabilities, RustSec <https://rustsec.org/> is 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
@@ -169,3 +168,4 @@ EXAMPLES
 
 SEE ALSO
        cargo(1), cargo-login(1), cargo-publish(1)
+

src/doc/src/commands/cargo-yank.md

@@ -50,16 +50,18 @@ requirements, following a given release being yanked:
 
 ### When to yank
 
-Crates should only be yanked in exceptional circumstances, for example,
-license/copyright issues, accidental inclusion of
-[PII](https://en.wikipedia.org/wiki/Personal_data), credentials, etc...
-In the case of security vulnerabilities, [RustSec](https://rustsec.org/) is
-typically a less disruptive mechanism to inform users and encourage them to
-upgrade, and avoids the possibility of significant downstream disruption
+Crates should only be yanked in exceptional circumstances, for example, an
+accidental publish, an unintentional SemVer breakages, or a significantly
+broken and unusable crate. In the case of security vulnerabilities, [RustSec]
+is 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.
+
+[RustSec]: https://rustsec.org/
 
 ## OPTIONS
 

src/etc/man/cargo-yank.1

@@ -81,16 +81,16 @@ T}
 .TE
 .sp
 .SS "When to yank"
-Crates should only be yanked in exceptional circumstances, for example,
-license/copyright issues, accidental inclusion of
-\fIPII\fR <https://en.wikipedia.org/wiki/Personal_data>, credentials, etc\[u2026]
-In the case of security vulnerabilities, \fIRustSec\fR <https://rustsec.org/> is
-typically a less disruptive mechanism to inform users and encourage them to
-upgrade, and avoids the possibility of significant downstream disruption
+Crates should only be yanked in exceptional circumstances, for example, an
+accidental publish, an unintentional SemVer breakages, or a significantly
+broken and unusable crate. In the case of security vulnerabilities, \fIRustSec\fR <https://rustsec.org/>
+is 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.
 .sp
-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.
 .SH "OPTIONS"
 .SS "Yank Options"
 .sp