Prompt crate owner with list of broken dependencies upon yanking action

[WalterSmuts]

A yank can cause dependent crates to be un-usable for new users. The user will experience a dependency resolution failure on the dependency of the crate they're trying to download:

error: failed to select a version for the requirement <....>

Currently this type of failure is not presented to the user performing the yank. My suggestion is to present the yanking user with all the dependent crates (okay, we're limited to those listed on crates.io) that the yank action would break, prompting the user to confirm or abort the yank-action.

The intended use-case:
A crate owner finds an obscure bug in their library. It is unlikely that dependent crates use the library in a way to trigger the bug, but for completeness the user wants to yank the crate, fix the bug, and publish the new version. If the user yanks their library before publishing the fix, the dependent crates would become unusable by new users. The prompt would present the owner with the impact of the yank action. The owner can then re-asses their plan and, if appropriate, publish the fix first and then yank the previous version.

This idea goes hand-in-hand with notifying the owners of crates that are broken by a yank-action. That idea is discussed here #5230

[Turbo87]

I agree that we should warn the maintainers about the consequences of yanking a crate.

IMHO crates/versions shouldn't even be yanked just because there are bugs in them. Just publish a new bugfix on top of the existing version and then cargo should pick up that new version automatically.

I haven't been around when the yanking feature was introduced, but I'm quite curious what the rationale for it was, because I don't know any other package ecosystems that allow this.

[WalterSmuts]

Interesting! I never really questioned the yanking feature but now that I think of it it seems a bit strange.

Thinking it through now, I agree yanking should not really be used for bug-fixes. The only scenario I can think of where yanking would be appropriate is if there was a minor version bump that included a feature that is fundamentally flawed. In this case you cannot just fix the issue by submitting a new patch version. The correct course of action would be to yank the latest minor version.

Weirdly AFAICT you then would need a major version bump if you want to add a minor version change after the yank. I.e. If you had x.0.y and publish x.1.y which contains a bug, then yank x.1.y, you can no-longer publish x.2.y without breaking semver policy if x.2.y does not have the same API as x.1.y. You would need to do a major version bump for the next feature.

Point is, I can see how minor versions that have a flawed api addition would benefit form the yanking feature. Although I agree, it's way more niche than I would've thought.

[Turbo87]

I think the only valid use case for yanking is if there is a high severity security issue in a published version or some malicious code was published for whatever reason without the maintainer's consent. in the JS ecosystem you would probably contact the npm support in that case and they would properly delete the version. maybe the reason for the yanking feature here was to reduce the support burden of the crates.io team back then.

in any case, IMHO we should add a warning to the yanking UI teaching the maintainers in which situations it is appropriate to yank a version.