Allow module owner to delete a module

[alerickson]

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

[he852100]

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.

[vpopescu]

+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]

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 (Sydney Smith (@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]

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.