[RFC3660] Crate Deletions New small proposal

Web Presence
1

Thank you so much @carols10cents , I'm here.

Salute to all the experts here! I'm a Rust newbie who has gone through great lengths to scale China's "Great Firewall" (GFW) to be here. After seeing this question, I couldn't help but chime in with some humble suggestions.

I've forked the RFC repository, but I'm feeling a bit nervous about whether submitting a PR directly would be too presumptuous, so I'm leaving a comment here first to share my organized thoughts. The original proposal was written in Chinese and then translated using deepseek, so I hope it's understandable.

If it's convenient, I'd appreciate any guidance from the experts on how a newbie like me can contribute to Rust. Thank you again! Below are my small suggestions:

New Proposal

Prerequisites

Record crate status in crates.io with the following states:

pub enum CrateStatus {    
    /// Clients do not update this version but allow developers to specify it manually.
    PreRelease(TimeRange),    
    Release, // default status.
    /// This version should be prominently marked on both the website and client.
    LimitedRelease(SemVerRange),
    GoverningRelease(TimeRange),
    /// Clients do not update this version but allow developers to specify it manually.
    PreDelete(TimeRange), 
}

These statuses will support the deletion mechanisms below.

Deletion Mechanisms

1. Author-Initiated Deletion

  • Crates with version 0.1.x published less than 8 hours ago.

2. Conditional Deletion

  • Long-unmaintained crates with version 0.1.x.

3. Manual Deletion

  • Crates with critical issues and no active maintainers.

Rationale

0.1.x and 8h

Crates with version 0.1.x on crates.io are typically experimental. Authors consider them unsuitable for production use, aligning with SemVer conventions. Most authors adhere to this practice.

If a crate was published for learning purposes, authors often wish to delete it after achieving their goals. However, current policies prevent such deletions. Thus, providing a time window (e.g., 8 hours or longer) before indexing these versions is essential.

Such crates should initially have the status PreRelease(0h..8h). During this window, authors may freely delete them. After expiration, the status automatically transitions to Release.

Automated Deletion

Due to historical policies, many 0.1.x crates on crates.io are unmaintained and occupy desirable names (e.g., reqwest vs. request). This creates confusion and technical debt. New developers should not need to navigate such legacy issues.

A scheduled task will check 0.1.x crates in Release status and set their status to GoverningRelease(0d..90d). If no maintenance occurs within 90 days, the status transitions to PreDelete(0d..3d), and authors are notified via email. If unresolved after 3 days, the crate name enters a pre-deletion state on crates.io, allowing others to claim it.

Once a new crate uses the name, the system permanently deletes the old crate.

Manual Deletion

For critical issues in active crates, authors may request deletion by setting the status to PreDelete(0d..3d). After submitting a fixed version, authors can delete the problematic version at an appropriate time.

Direct deletions may impact dependent projects. Client tools must warn users about deleted versions and automatically upgrade to fixed versions. For abandoned crates with critical issues, the crates.io team may manually set the status to PreDelete(0d..60d). If the original maintainer returns during this period and provides a fix, only the problematic version is deleted.

Caching Considerations

Testing crates have limited impact and require no special handling. For widely used crates, client tools must support version deprecation warnings and automatic upgrades to fixed versions.

Renaming Proposal

The LimitedRelease status can facilitate name swaps between crates. For example, renaming reqwest(0.11.0) to request(1.1.1) would follow this process:

  1. The request author transfers ownership to reqwest and adopts a new name (e.g., support_community_development).
  2. The reqwest author accepts the name request.
  3. The system sets reqwest to LimitedRelease(0..0.11.0).
  4. The system sets request to LimitedRelease(2.0.0..). Name changes are breaking changes and require a major version bump.
  5. The system sets request to LimitedRelease(0..1.1.1).

Clients resolving dependencies for request within 0..1.1.1 will use the original crate, while versions >=2.0.0 will resolve to the renamed reqwest crate. This preserves backward compatibility and resolves legacy naming conflicts.

Drawbacks

Significant coding effort is anticipated.

2 Likes
2

I would recommend focusing on the motivation (use cases, problems) and putting that front and then tie everything back to how it is helping with that. I would then next focus on the states and how they work (ie a user-level reference explanation). If you can find some related prior art, that would also be great as it helps to show how this applies the lessons others have learned.

Crates with version 0.1.x on crates.io are typically experimental. Authors consider them unsuitable for production use, aligning with SemVer conventions. Most authors adhere to this practice.

Not always. Almost every crate of mine has started at 0.1 and I think I still have a couple that are at that version.

Also, something important to keep in mind is that Cargo diverges from SemVer in how 0.x releases are treated.

1 Like
3

hello~ @epage :eyes:

This is my first time contributing my thoughts to Rust, and I mainly rely on translation software to communicate with everyone. I hope this doesn't affect understanding.

Regarding the issue you mentioned, the reason for specifically highlighting 0.1.x has already taken this situation into account. As I mentioned in the rationale, after a certain period, the 0.1.x version will transition from PreRelease to Release status on the server, which is actually seamless for developers. The 0.1.x version should appear largely unchanged in the eyes of developers. Whether to perform a deletion operation is entirely up to the developers themselves. I believe this is highly beneficial for maintaining crates.io. If your crate is at 0.1.x and hasn't been maintained for a long time, yet has helped many people, then you should consider upgrading to 0.2.x or 1.0.0. This proposal only allows for manual deletion by the website maintainers in cases where there are significant issues with a crate. In all other scenarios, there will be no automatic deletions.

I am still getting familiar with how to communicate with others in this community. If there are any inappropriate actions on my part, I will correct them as soon as I am aware.

1 Like