Request: Provide an official way to *deprecate* a crate. NOT yank. Yank is stupid

tools and infrastructure
1

Yank breaks things. It is also way too alarmist.

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.

NPM has this for decades. It is a known practice.

10 Likes
2

That is a very good proposal, and dozens similar to that one

2 Likes
3

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.

4

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.

1 Like
5

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.

6 Likes
6

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.

4 Likes
7

Agreed. The current situation is not great.

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.

1 Like
8

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).

2 Likes
9

I think that any maintenance flag should decay over time. Otherwise one could set a crate as maintained, forget about it for 5 years, and the whole time the crate shows up as maintained. The system does not work if the information isn't up to date.

10

Not every crate requires active maintenance to keep it up-to-date though. I feel like "yep, still alive" commits or tags is just unnecessary noise (just like "fix formatting" commits). It is rare though.

9 Likes
11

That's why it makes sense to have such a status, if it were to exist, be metadata outside the package like yanking is — so that it can be updated in whichever way without publishing a new version.

I imagine crates.io showing something like “The owner of this package declared that it was [deprecated | still maintained] [<time period> ago]", so that readers can make their own judgement about age.

(Of course, there’s no robust way to stop maintainers from automating posting "still maintained"…)

2 Likes
12

I could see not mentioning how long it has been since the last activity (including a publishing clicking "I'm still here" on the crate settings) until after a certain period of time, like 6 months or a year. I could also see crates.io emailing the pubishers letting them know certain crates will be leaving the grace window soon unless some activity is present, linking to a "I'm still here" link.

1 Like
13

This request of mine is more about library maintainers/authors willfully, explicitly choose to deprecate a package or a version of a package. It's not about automatically and implicitly burdening them with false activities.

In other words, this proposal of mine is focusing more on the side of active library authors/maintainers than on the users of the libraries.

If crates.io really does that, I could see a controversy from miles away. Many would be annoyed. I myself would hate this.

If the users really want to see maintainence status of a package, they should check the git activities themselves, and compare it with issues, pull requests, the size of the codebase, the completeness of the APIs, etc. all by themselves (or some automated tools).

Anyway, it'd be nice if the discussion could focus back on cargo deprecate vs. cargo yank.

3 Likes
14

I think this should work like "last seen online" status in messenging apps: some people would like to share this, others would find it annoying. In consequence, the crate author could opt in to setting such status information on their crates, but they shouldn't be forced. The opt-in could be the same as the first time you press a "this is still maintained" button on a particular crate. (And you should be able to change your mind and opt out again later.)

Email reminders should be a separate opt-in; I believe it's only acceptable to send each crate author an email unmasked for once (once per person not per crate), the first time one of their crates (that they have opted in to share a status in the first place, as described above) is about to become considered "old".

That email can then contain a section like "This is a one-time demonstration of the crate grace window notification feature. Click here if you do want to receive this kind of email again in the future."

I believe the email opt-in should be per-user, whereas the setting of whether to share any status information should be per-crate.

2 Likes
15

If we are to introduce such status, I think it should be possible to ping it using CI or even periodically update it automatically using last commit date (if the repository field is provided). In other words, if there is some activity in repository usually we can consider the crate as "maintained" even if there are no new releases.

16

I think that this should be a separate state ("maintenance not required") that is distinct from both maintained and unmaintained. I agree that a large number of crates, specially if they have little or no dependencies, are evergreen and require no maintenance.

I think one trouble is that even crates that don't normally require maintenance may require it exceptionally (for example, a compiler bug was fixed but this crate was relying on it - if the crate owner is unresponsive, this should downgrade the crate from "maintenance not required" to "unmaintained")

Anyway all such schemes for signaling maintenance should probably be opt-in. If the author does nothing, it should work as today.

2 Likes
17

Not to bikeshed too much but I'm not sure I love that phrasing. As you say, some degree maintenance is required. It just might be very infrequent. Admittedly I'm not entirely sure how to word it but "maintenance not required" sounds far too close to "abandoned" in effect. Whereas in this case the maintainer should still be responsive if serious bugs or security problems do surface.

18

Maybe "feature complete" with "bug fixes only"

Well there's many things we can surface about the maintenance status of a software, crates.io will probably only display a subset of the possible information to be presented

1 Like
19

The problem of "done" crates vs outdated ones is somewhat separate from marking old releases as deprecated or even intentionally marking whole crates as deprecated.

Anyway, it's a common sentiment that projects can be done and never updated, but from my analysis of crates.io data this is a small minority of crates in practice.

First of all, most of the crates that theoretically don't have to be changed, still get updates from time to time. A small tweak, a dependency update, bump of Rust edition, compatibility with a new OS release, or an optimization for a newer CPU. There's still churn, just slower.

Among crates that had no updates for 3+ years, there are some that are really "done" and don't need to be updated, but IMO there are very few such crates compared to the number of old crates that are just out of date, unfinished, and abandoned. Exact number depends on how you define the terms. In my estimate it's on the order of 10-100 evergreen crates that are worth using, maybe 1000 if you stretch it, but that's among 100,000+ old crates.

If you look at this from a user perspective, if they stumble upon an old crate, it's a 99% chance that it will be some outdated abandonware. The sheer numbers create a very strong correlation between old=bad, so it's automatically harder to convince users that an old crate can be fine. It's not the fault of the authors who made the few genuinely once-and-done crates, but their crates still suffer because of that. So IMO giving authors ability to affirm that an old crate is still perfectly fine, and using that to help users filter out abandoned junk, is a helpful service to both users and authors.

When crates.io has 250,000+ crates and quickly growing, it is now a numbers game. Not doing anything about the 99% of crates because of a 1% of exceptions still hurts the few exceptional crates by drowning them in the sea of outdated crates.

(On lib.rs I'm trying to help the "done" crates by having heuristics to detect them, such as whether they are releasing patch versions, how long they've been in development been between first and latest release, and I'm scaling my freshness thresholds to the crates' average release frequency)

3 Likes
20

I believe the PyPI name for it is "mature".