{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigluxfqxdauu2sgvug2grd2po3hbrozqk6lki2qefokvk5mwa2um4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjjgiujmlcv2"
  },
  "path": "/t/request-provide-an-official-way-to-deprecate-a-crate-not-yank-yank-is-stupid/24174#post_1",
  "publishedAt": "2026-04-15T06:18:38.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Yank breaks things. It is also way too alarmist.\n\nLibrary developers nowadays just published a new version with `-deprecated` suffix or something, but this is a hack.\n\nOther library developers publish a new major versions with empty code. This too is a hack.\n\nI 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.\n\nTools and automated bots. They are unlikely to recognize the hacks I mentioned as \"deprecation\" because their semantics aren't defined.\n\nConsumer 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.\n\nNPM has this for decades. It is a known practice.",
  "title": "Request: Provide an official way to *deprecate* a crate. NOT yank. Yank is stupid"
}