.NET Package Maintenance (deprecation)

[leecow]

.NET Package Maintenance

.NET Core was released in June 2016, and over the last six years, many thousands of NuGet packages have been published under the .NET umbrella. Many of these packages are legacy or out-of-support already. As things stand today, there is no information associated with these packages to indicate their support status.

To provide developers with better package support status information, the .NET team will start using the NuGet Package Deprecation feature. Deprecated packages remain visible on nuget.org, to clients such as Visual Studio and the .NET CLI, and can be restored by projects. In addition to updating existing packages, we will mark packages as appropriate when new versions are released so that developers can access up-to-date information on the packages they use.

Which Packages will be deprecated

As a general principle, packages that are out of support per the .NET Support Policy will be marked deprecated. Packages that were part of abandoned projects, such as dnx, will be marked deprecated, as will packages that were part of earlier preview releases.

After we are caught up marking previously released packages, we will update packages when new versions are released. For example, when .NET 6.0.10 releases, package versions for 6.0.9 will be marked deprecated.

AspNetCore 2.2 is a unique category, particularly around .NET Framework usage. We will work out how best to address these packages getting caught up and staying current at each release.

Timing

We would like to begin the package marking process next week and first want to hear if there are any issues that have not been considered. Please see the .NET Package Deprecation list and use this issue to comment.

[SeanKilleen]

I appreciate the heads up on this.

My only concern -- In my mind, when I think of deprecation, I think:

• The package is no longer supported/maintained and users should upgrade for the health of their application (in line with the first use cases you mention)
• Something is an issue in a package and folks should update ASAP. Major bug, vulnerability, etc.
• An unintended or bad publish, which likely falls into "major bug" territory above where users would be advised not to use that package.

However,

We will update packages when new versions are released. For example, when .NET 6.0.10 releases, package versions for 6.0.9 will be marked deprecated.

Seems like it could risk creating a noise issue in the ecosystem. There isn't anything wrong with the package in that instance; we're just trying to encourage users to stay current. And while I think encouraging to stay current is a good goal, I think deprecating all prior packages beyond current seems a bit heavy-handed to get there, and may risk users treating deprecation as less concerning or worthy of their investigation, harming the overall goal.

A better investment toward this goal may be tooling or guidance or upgrade guides that make upgrading and testing upgrades minimally risky, thus enabling more to feel "safe" about approaching them.

[KalleOlaviNiemitalo]

AspNetCore 2.2 is a unique category, particularly around .NET Framework usage.

Do you mean AspNetCore 2.1? That's what is supported on .NET Framework. https://dotnet.microsoft.com/platform/support/policy/aspnetcore-2.1

[terrajobst]

@SeanKilleen

A better investment toward this goal may be tooling or guidance or upgrade guides that make upgrading and testing upgrades minimally risky, thus enabling more to feel "safe" about approaching them.

I like that. I have seen folks running "update all" in VS's UI just in case. Some folks even forget to uncheck "include prerelease" which then creates more problems down the road.

Maybe NuGet should have safe update all, i.e. update to latest stable minor version? /cc @JonDouglas @clairernovotny

$ dotnet refresh

or

$ dotnet restore --refresh

Basically "update package references to latest stable minor (if the package reference is a stable version) or latest minor prerelease (if the package reference is a prerelease).

[SeanKilleen]

@terrajobst yes, I think something like that would lead to more impact.

If the goal is ".NET projects keep their dependencies up to date", I think tooling like the above -- as well as great release notes and upgrade guidance -- will better enable it without the negative impact of diluting the meaning of a deprecation.

[schemburkar]

Can the packages be marked outdated rather than deprecated?

The subtle difference being that it tells consumers that the package is still fine, just not latest vs it might have known vulnerabilities and is now deprecated

I do agree with @SeanKilleen that there might be noise in the ecosystem when this happens.

[leecow]

Thanks, @KalleOlaviNiemitalo. What I'm referring to with AspNetCore 2.2 is that a number of new features were added which are not in 2.1 creating a support culdesac. Some AspNetCore / .NET Framework customers depend on these features so we need to be thoughtful in how we handle that set of 2.2 packages.

[leecow]

@schemburkar - I understand the distinction you're pointing out. We want to use the NuGet feature so that the marking is leveraged by appropriate tools (VS, etc) as seamlessly as possible. I didn't see outdated in the NuGet catalog-resource docs though certainly may have missed it?

[schemburkar]

I didn't see outdated in the NuGet catalog-resource docs though certainly may have missed it?

I thought it was but I could be wrong

Additional point is that would there be a ingestion period from the day newer version arrives and the older version is marked?
Coz I'm thinking of extensions and library authors talking some time till they consume the latest version and update pinned dependencies

[SeanKilleen]

@schemburkar

Can the packages be marked outdated rather than deprecated?

Doesn't this happen by virtue of a new package being created? Nuget automatically finds that there's a new package available. What purpose would such a label serve in that case? (just curious.) At that point it seems like it's a solved problem?

[schemburkar]

@SeanKilleen agreed. I was looking at it from the angle of project maintenance perspective where you would now see a ton of packages that are marked deprecated and some of them due to vulnerablities vs some just being stale.

@leecow I was looking into the nuget announcement of the deprecated feature and it turns out the package can post a message why it's deprecated. So if all the packages that will be deprecated have a clear message it would help

[JonDouglas]

Hi friends,

We have three words we use over at NuGet. TL;DR:

• Deprecated - Please don't use this for a disclosed reason and please use this suggested alternative(if any).
• Vulnerable(NEW) - Please don't use this due to disclosed/known vulnerability and update/replace/remove/do nothing accordingly.
• Outdated - Please consider using a newer version.

Similar to Immo's idea, we would like to work on NuGet/Home#4103 (comment) but it will need time for a thoughtful design to account for cases like this.

Go 👍 and comment! NuGet/Home#4103 though if you're interested in that experience.

Additionally for the all-up experience, we're trying to provide warnings/errors for each of these three words. Right now it's proposed as dotnet audit:

Go 👍 and comment! NuGet/Home#11549

Hope this helps.