Skip to content
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

Open
crowlKats opened this issue Jan 21, 2025 · 7 comments
Open

Comments

@crowlKats
Copy link
Collaborator

crowlKats commented Jan 21, 2025

We need a way to delete a package version, however we should keep this to be under very specific circumstances. one idea would be:

  • less than X downloads
  • published less than X ago
  • No dependents

this should be sufficient to enable this capability for the usecase people have, while still being true to the rule of being immutable.

@crowlKats crowlKats added this to JSR Jan 21, 2025
@github-project-automation github-project-automation bot moved this to Needs Triage in JSR Jan 21, 2025
@crowlKats crowlKats moved this from Needs Triage to Needs Plan in JSR Jan 21, 2025
@Inbestigator
Copy link

Inbestigator commented Jan 21, 2025

Maybe if not latest version? (Unless only version)

@BlackAsLight
Copy link

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.

@Inbestigator
Copy link

Maybe yanking could actually be more effective (like yanking all versions will allow you to delete the project etc.)

@crowlKats
Copy link
Collaborator Author

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

@yuhr
Copy link

yuhr commented Jan 21, 2025

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

@crowlKats
Copy link
Collaborator Author

@yuhr thats why the idea is that there can be no dependents and very little downloads (ie 10 downloads)

@yuhr
Copy link

yuhr commented Jan 21, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Needs Plan
Development

No branches or pull requests

4 participants