-
Notifications
You must be signed in to change notification settings - Fork 656
Closed
Labels
C-enhancement ✨Category: Adding new behavior or a change to the way an existing feature worksCategory: Adding new behavior or a change to the way an existing feature works
Description
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.
Metadata
Metadata
Assignees
Labels
C-enhancement ✨Category: Adding new behavior or a change to the way an existing feature worksCategory: Adding new behavior or a change to the way an existing feature works
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
kornelski commentedon Feb 7, 2017
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 commentedon Feb 7, 2017
@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 commentedon Feb 8, 2017
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 commentedon Feb 8, 2017
@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 commentedon Feb 8, 2017
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: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 commentedon May 14, 2017
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!