Gently phase out support for older NuGet packages with MyGet

1 minute read

Simply deleting those packages is most likely not the best option. You probably have no idea of who still depends on them, either directly or through another package depending on it, even though you could try to analyze your source control repositories and get some first insights.

MyGet now has a new feature that allows you to indicate whether or not you still support a given package.

Toggle Package Support

When navigating to the package details page on MyGet, you'll notice that a new button has been added next to each entry in the package history listing, as shown below.

You can easily toggle the state of a package by marking it as listed or unlisted. We'll also alert you about the impact of your change so you can't break anything by accidentally clicking the button.

Package Listing Explained

By default, all new packages are listed obviously, otherwise you wouldn't be able to download the package from the feed. However, we want to give you the ability to explicitly unlist a package from your feeds. By unlisting a package, you indicate you no longer wish to support that specific version of a package. In essence, you want to give people a gentle push towards upgrading to a newer version. That's exactly the goal of this feature.

Unlisting a package is not the same as permanently deleting a package from the feed. You could look at it as performing a soft delete. This also means that this operation can be undone! The operation of listing or unlisting a package is restricted to feed owners, feed co-owners *and *feed contributors. If you only have package contributor permissions for the feed, you also have to be the explicit package owner.

The reason we require these permissions are obvious: this is a breaking change in your package workflow! If you are using a no-checkin policy for NuGet packages, make sure you inform people to check-in this package into their VCS so you don't break their stuff.

Be a good citizen when using this feature. In a controlled enterprise environment, this should be easy.

Remember: upgrading a dependency is a consumer responsibility, so it's the consumer's decision when to upgrade.

This feature is all about discontinuing a NuGet package while maintaining an upgrade path.

Leave a Comment