Skip to content

Add a deprecated property to Cargo.toml #549

@XAMPPRocky

Description

@XAMPPRocky
Member

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.

Activity

kornelski

kornelski commented on Feb 7, 2017

@kornelski
Contributor

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

XAMPPRocky commented on Feb 7, 2017

@XAMPPRocky
MemberAuthor

@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

carols10cents commented on Feb 8, 2017

@carols10cents
Member

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

XAMPPRocky commented on Feb 8, 2017

@XAMPPRocky
MemberAuthor

@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

kornelski commented on Feb 8, 2017

@kornelski
Contributor

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

carols10cents commented on May 14, 2017

@carols10cents
Member

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancement ✨Category: Adding new behavior or a change to the way an existing feature works

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @kornelski@carols10cents@XAMPPRocky

        Issue actions

          Add a deprecated property to Cargo.toml · Issue #549 · rust-lang/crates.io