-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ability to delete of published version under certain circumstances #899
Comments
|
To add to this, I think it would be beneficial to exclude these versions when downloading an existing lib and looking for libs to deduplicate but still included if adding a new dependency to a project. |
Maybe yanking could actually be more effective (like yanking all versions will allow you to delete the project etc.) |
no, yanking allows versions to still be available, and deleting could break a lot. ie lets say std/collections yanked all versions and then deleted the module, that would completely destroy everything |
Versions that satisfy the circumstances must be shown with a noticeable BIG RED WARNING label about the endangerment in the Web UI. Otherwise random users might experience broken builds unexpectedly (like me experienced the same in npmjs.com). |
@yuhr thats why the idea is that there can be no dependents and very little downloads (ie 10 downloads) |
I mean, we can't measure number of dependents at all, because not all actual dependents are published on JSR. Internal use only softwares might depend on such a low-reputation version. On the other hand, number of downloads would be trustable. Thresholding at ~10 downloads sounds completely viable to me. |
We need a way to delete a package version, however we should keep this to be under very specific circumstances. one idea would be:
this should be sufficient to enable this capability for the usecase people have, while still being true to the rule of being immutable.
The text was updated successfully, but these errors were encountered: