Library developers nowadays just published a new version with -deprecated suffix or something, but this is a hack.
Other library developers publish a new major versions with empty code. This too is a hack.
I just want a way to mark independent versions of packages or ranges of versions of packages as deprecated along with a message explaining the reason. Not as forceful as a yank. And far more semantically relevant than the two hacks I described.
Tools and automated bots. They are unlikely to recognize the hacks I mentioned as "deprecation" because their semantics aren't defined.
Consumer developers, upon seeing the deprecation messages, they can either choose to ignore them, or fix them in their free time, or let the tools and automated bots (which can now correctly intepret deprecation as deprecation) fix it for them.
It would mean some kind of crates.io-specific metadata, but why not have maintenance status associated with versions? New compatible versions can mark old ones as "update available", maintainers could mark version series as "unmaintained" or "dangerous", and folks could become maintainers and "resurrect" a version series for $reasons. I think yanking is fine for pervasive unsoundness (i.e., some core API is unsound, not necessarily "a function that 'no one' uses is unsound"). This metadata could be used by cargo outdated and cargo audit to recommend actions.
This could be resolved by a deeper integration with the RustSec database which already has unmaintained advisories. crates.io already pulls RustSec security advisories (indirectly through GithHub, but still), so I think it could be improved further. In other words, this metadata does not have to be part of the crates.io registry.
I think the author of a crate should be able to mark their crate as unmaintained or deprecated directly from the crates.io web-interface, without having to open a PR on a third-party github repository.
I guess where the deprecation metadata is actually stored can be flexible.
However, regardless of where it is stored, I think it's important (in the user-facing side) that crate authors and maintainers don't have to go through any hoops or login to any 3rd-party services just to deprecate a package/version.
The crate author/maintainer should be able to run cargo deprecate <PKG_NAME>[@<VERSION_RANGE>] -m <REASON> as long as they have valid token on their ~/.cargo/credentials.toml.
Alternatively, they can just deprecate the packages/versions on the web UI of crates.io.
As a maintainer, I don't want users of my libraries to run into old bugs I've already fixed. It wastes their time, and mine too if they complain about it to me.
Even if old versions technically work fine, there's an ecosystem-wide cost of code bloat caused by multiple semver major versions being used at the same time.
So I'd like to nudge users more to upgrade, at least move off super old versions. I'm currently using yank for this, but it's too harsh. I'd rather not break builds without Cargo.lock, just make noise about old versions to ensure users are staying on the old versions intentionally and not just by inertia.
This Development-cycle in Cargo: 1.78 | Inside Rust Blog has some context on a potential replacement for the old maintenance status badges. I believe it is mainly lacking in someone driving it forward (further exploring the space and experimenting with how it should be designed and implemented).