This project is read-only.

Restore the ability to permanently delete obsolete package versions


BUG: "Permanently deleting packages is not supported, but you can control how they are listed."

Per email conversation with David Ebbo, I hereby formally request that this functionality be restored to the site because, in my opinion, package authors and/or copyright owners (I am both) must have veto authority over which package versions are retained forever.

This very recent "policy" change to the web site was made without any kind of notice and after material had already been submitted and without any input from the "community" (to my knowledge).

Here are some highlights from the email conversation (summarized):

One of my projects (Eagle) is still formally in beta and I do not wish to retain stale beta versions forever, no matter where they are being used. I want people to use the latest version because I have no interest in getting feedback and/or bug reports for issues that I have already fixed.

People who really require previous versions are free to use my source code repository, sync to the appropriate release tag (or any other tag) and build the necessary binaries from there.

It bothers me a great deal that NuGet has suddenly changed this "policy" regarding the retention of stale package versions without consulting with the community (to my knowledge), without any prior notice, and without the ability of the package author and/or copyright owners to object or have any veto authority over which versions are retained [forever].

Your sister site (i.e. initially did not support the permanent deletion of old package versions; however, they changed their tune because their customers (i.e. those who actually produce the free software) demanded it.


Haacked wrote Dec 27, 2011 at 5:31 AM

Thanks for the feature suggestion! This would be a feature of the website, not the NuGet client. We already have an issue related to this over there. is a complete reimplementation of the original gallery with a much improved data schema. As we were getting closer to release, we ran into interesting bugs with delete such as: that we need to resolve.

As you can see from the issues, we did discuss this publicly in the issue tracker.

And note that even though the functionality no longer exists on the site, you can still ask us to delete the package. There are a few places where we supply a delete link. In the case of Eagle, it would probably be: Clicking on that link takes you to the following content. Note this policy is not unlike policies with other package managers such as Ruby Gems.

Why can’t I delete my package?
Our policy is to only permanently delete NuGet packages that really need it, such as packages that contain passwords, malicious/harmful code, etc. This policy is very similar to the policies employed by other package managers such as Ruby Gems.

Unlisting the package will remove the package from being available in the NuGet. The package is still available for download as a dependency for three main reasons.

Other packages may depend on that package. Those packages might not necessarily be in this gallery.
Ensures that folks using NuGet without committing packages (package restore) will not be broken.
Helps ensure that important community owned packages are not mass deleted.

If you need the package permanently removed, click on the Report Abuse link and we'll take care of it for you. PLEASE ONLY DO THIS IF THERE IS AN URGENT PROBLEM WITH THE PACKAGE. (Passwords, malicious code, etc). Even if you remove it, it’s prudent to immediately reset any passwords/sensitive data you accidentally pushed instead of waiting for us to delete the package.

In most cases, the harm in deleting a package is more problematic than the cure. In NuGet 1.5, we introduced the ability to unlist a package. For all intents and purposes, the package appears to be deleted from the site. There's only a few cases where the package still exists and those would be cases that would break existing folks if the package were to be missing.

That should address your primary concerns as folks will be encouraged to upgrade when you release new packages. Consider that even if you did delete the package from, you still don't delete it from existing projects. So in terms of support calls for older versions, the effects of deleting them and unlisting them are the same.

In fact, I'd argue that deleting the package will result in more support calls in the cases where you've broken existing packages or folks who are using the package restore feature. Keep in mind, that latter case would actually result in their builds being broken without any clue why other than your library's absence being the cause.

davidebbo wrote Dec 27, 2011 at 5:32 AM

FYI, I started a discussion on But note that in the context of the 'don't commit packages' workflow, I don't think the case you give (not wanting to support old versions) is a valid case for completely tanking packages. Unlisting them is the correct thing to do. But let's take the discussion there, as people will not see it here.

Haacked wrote Dec 27, 2011 at 5:39 AM

BTW, David Ebbo started a related discussion here: Probably a better place to discuss this. :)

davidebbo wrote Dec 27, 2011 at 6:05 AM

Let's try to keep the discussion on, as this is not a bug, but a design issue. Also note that this bug is in the obsolete nugetgallery project, so it is in the wrong place.

mistachkin wrote Dec 27, 2011 at 6:07 AM

To a certain extent, I see your point; however, you do not have superior knowledge of my users and their use cases. Also, as the owner/maintainer of the package(s) in question, I need to retain the ability to control their distribution, at the very least through the official distribution channels (i.e. obviously random people are free to distribute copies of whatever version). My personal view is that NuGet provides a [valuable] service in this regard; however, I do not accept the idea that I must relinquish my ability to control what versions are retained [forever] by said service.