You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our typical policy for crates.io, designed to prevent rampant spontaneous breakage (a la npm's left-pad fiasco), is that crates cannot be "un-published". We do allow "yanking", however, to allow crate authors to designate that Cargo should not use that particular version unless a lockfile already exists using that version. In the interest of giving crate authors a bit more agency, I propose that yanking every version of a crate should prevent that crate from showing up in search results, category listings, etc.
Rationale: if someone wants to prevent their crate from being used, a crate author can always upload a new version of the crate that deletes (or otherwise breaks) all the code in the crate, and yank every other version. This is more disruptive than simply allowing crates to be hidden from search results if every version is yanked. Furthermore, as per our usual policy, yanked crates would still be usable for those who have already started using them, so no ecosystem breakage will occur. This proposal is not suggesting to remove the crate's landing page itself if every version is yanked, though it may be useful to have some sort of special badge noting that every version is yanked.
The text was updated successfully, but these errors were encountered:
This proposal is not suggesting to remove the crate's landing page itself if every version is yanked
This is actually the current behavior; you get a "there are no published versions of this crate" page. I am not sure what the status code is off the top of my head, but you can no longer see any information about the crate.
I very much agree with this proposal; crates that are yanked clutter up search results, and make my author dashboard more irritating (they show up there too, and may have similar names to things that replaced them which is confusing).
I'd say that there also needs to be a mechanism to delete crates though. I understand wanting to avoid the leftpad problem, but enforcing rules blindly will lead to trouble down the road. For example, if I accidentally push a crate from work that I did not have the legal authority to publish, but don't want ot mention that publically, currently the crates.io team simply refuses to remove the crate. Restricting what authors are allowed to do with their own code is not an acceptable way to "fix" the leftpad problem (unless you also give those authors a way to maintain their own code if they want, and the "no deletions" policy is just a local policy that applies to using the centralized crates.io instance of the site).
Our typical policy for crates.io, designed to prevent rampant spontaneous breakage (a la npm's left-pad fiasco), is that crates cannot be "un-published". We do allow "yanking", however, to allow crate authors to designate that Cargo should not use that particular version unless a lockfile already exists using that version. In the interest of giving crate authors a bit more agency, I propose that yanking every version of a crate should prevent that crate from showing up in search results, category listings, etc.
Rationale: if someone wants to prevent their crate from being used, a crate author can always upload a new version of the crate that deletes (or otherwise breaks) all the code in the crate, and yank every other version. This is more disruptive than simply allowing crates to be hidden from search results if every version is yanked. Furthermore, as per our usual policy, yanked crates would still be usable for those who have already started using them, so no ecosystem breakage will occur. This proposal is not suggesting to remove the crate's landing page itself if every version is yanked, though it may be useful to have some sort of special badge noting that every version is yanked.
The text was updated successfully, but these errors were encountered: