Add a deprecated property to Cargo.toml

[XAMPPRocky]

Seeing #542 makes me think that maybe there should be metadata info for that. For example adding a key to Cargo.toml, deprecated would allow for people to say their package is deprecated and maybe with a message detailing why, or redirecting viewers to another crate ie. "use ring instead". This would also help with the crate ranking proposal by allowing crates to essentially opt out of being shown, or getting a high search ranking.

[kornelski]

Updating of Cargo.toml requires publishing a new version, so there wouldn't be a way to deprecate an existing version.

But the functionality would certainly be useful. It could be implemented similarly to yank cargo command.

[XAMPPRocky]

@pornel AFAIR wasn't it proposed to allow updating Cargo.toml without requiring bumping the version number.

Irregardless this wouldn't be for a single version it would be for the whole crate. All versions of the crate would be deprecated. So it wouldn't be the worst thing if you were deprecating to put out a final version.

[carols10cents]

I feel like rather than a binary deprecated/not deprecated flag, it'd be more useful to have a "maintenance" or "support" or "maturity" field that could have a set of values. I had a proposal for something like this in one version of the rfc 1824 proposal, wdyt?

[XAMPPRocky]

@carols10cents Oh yeah, that is exactly it I must have forgotten that was there. I do think that list should have an additional deprecated, as there are cases where someone doesn't want support their crate and they don't want to transfer ownership of the project. Feel free to close this and continue discussion on the crate proposal RFC.

[kornelski]

I've mentioned deprecation of a specific version, because npm has this, and it's getting used. It's a free-form text, so people use it for various reasons:

• when latest node version is not compatible with an old release.
• when the package has been merged/split/renamed and users should migrate
• when a serious bug was discovered in an old version and users are urged to upgrade

So reasons for deprecation are a bit different than support/maintenance status of a crate.

Cargo 'yank' partially covers deprecation, but lacks ability to explain why the version was yanked. So maybe adding explanation to the yank command would be useful? (regardless of maintenance status property)

[carols10cents]

I'm going to close this issue-- I've added "deprecated" as a maintenance label that we'll add as part of #704 for cases when you want to deprecate the whole crate, and you can use the crate description to explain why or point to a new crate.

Adding a reason to "yank" is covered by rust-lang/cargo#2608.

Thanks!