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

Allow module owner to delete a module #87

Open
alerickson opened this issue Apr 7, 2020 · 4 comments
Open

Allow module owner to delete a module #87

alerickson opened this issue Apr 7, 2020 · 4 comments
Milestone

Comments

@alerickson
Copy link
Member

Proposing that module owners should be allowed to delete a module if it's been published in the past week.

@he852100
Copy link

he852100 commented Apr 14, 2020

I am completely incomprehensible and prohibit users from deleting modules.

When it is released. Less than one day, 12 hours or 1 hour or 1 minute. I hope to delete it within a certain period of time after posting a cloth.

it will not be used by anyone in a short time.

I often feel annoyed that new garbage has been generated. It has no way to benefit others or even themselves. I cannot delete it.

just now. There is a lot of invalid garbage in the repository. Users are very troubled.

Simultaneously. Please provide a user tag module. Allow users to mark modules or scripts sent by others as valid or invalid.Instead of counting on the publisher to tag it.

Due to cross-platform or version differences. A large number of scripts need to be marked to run on specific platforms or software versions. A large number of publishers have not been tested, or older versions do not support new platforms or software.

@SydneyhSmith SydneyhSmith added this to the Future milestone Apr 14, 2020
@vpopescu
Copy link

vpopescu commented Jul 28, 2020

+1. We are asked to send the request in by mail, but I've never gotten a reply back and the module was never deleted.

If someone accidentally publishes something confidential or damaging of the end user, it's a problem.
Also, it should be deleatable at any time if there are no other modules referencing it.

Another enhancement would be to create a "Do Not Link" flag, which would prevent people from linking to your module, and reduce the risk of breaking someone else's module. But I suspect this may be too controversial.

@bormm
Copy link

bormm commented Oct 23, 2020

Microsoft is not the owner of the hosted modules, so its not on Microsoft to decide how long the module will be available.

After first thinking I agreed with MS, that deleting modules breaks the build and that's bad.
But now I have created a CI/CD setup which created a lot of waste there, while optimizing the process, which I can't delete now.
So after also thinking some Minutes now about that:
People can't rely their business on free available packages from PowerShell or nuget.org gallery forever. Nothing is and will be forever, nor on the planet at all and of course not in this industry. This industry means last month is maybe very very long time ago. What is the benefit enforcing developers to provide old non-maintained and maybe defective packages using these repositories? What happens if something is destroyed, what if there is a bug? Microsoft can't maintain these packages but provide them forever, so they are responsible for all issues with these packages.

If someone build his business based on a package, he has to life with the risk the package will be removed and take care of caching it or make a support agreement with the provider of the package.

As they are not allowed to change them, and also not allowed to provide them without permission of the owner. This is not only a technical but also a legal issue.

So: Please Microsoft (@SydneyhSmith and @alerickson here currently) allow deleting packages at any time without restrictions and show a message to users that packages can be removed at any time and users should contact the package owner if they need a other agreement.

@DMoenks
Copy link

DMoenks commented Jul 30, 2023

Adding to this, the ability to actually delete a package would really be the preferred option.

A probably acceptable alternative to this would be the option to really unlist a package though, so that it doesn't show up for anyone anyhwere besides its owners and can't be downloaded programmatically, combined with an automatically generated warning, ...

  1. mentioning that the version someone tries to download is deprecated, ...
  2. while referring to the most recent version and ...
  3. possibly providing a URL to manually download the intended version

The manual download URL chould then be (de-)activatable by package owners, depending on if a specific version contains technical/security flaws or if they just want to deprecate that version for various reasons. This way, the availability of packages would be a little more controllable, while still keeping a history of packages and their versions in the gallery itself.

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

No branches or pull requests

6 participants