search

NuGet / NuGetGallery

NuGet Gallery is a package repository that powers https://www.nuget.org. Use this repo for reporting NuGet.org issues.
https://www.nuget.org/
Apache License 2.0
1.54k stars 644 forks source link

[Deprecation]: Automatically apply deprecation when new versions are uploaded #8872

Open loic-sharma opened 2 years ago

loic-sharma commented 2 years ago

Related Problem

Imagine my package Old has been replaced by New. I still support Old and upload new versions to fix security issues. Since I want all my customers to move to New, I deprecate all versions of Old.

Unfortunately, package deprecations only apply to existing versions: a newly uploaded version will not be marked as deprecated. I need to remember to login to nuget.org and deprecate each version after I upload it.

The Elevator Pitch

There should be a way to automatically apply a deprecation all versions of a package, including future uploaded versions.

Additional Context and Details

This is an ask from the Azure SDK team: https://www.nuget.org/packages/Microsoft.Azure.DocumentDB/

/cc @chgill-MSFT @petermarcu

kirankumarkolli commented 2 years ago

Cosmos DB V2 SDK's were deprecated. Even post deprecation we are bound to address critical security and bug fixes for existing customers. We uncovered that those updated packages are not not marked deprecated and its a manual process which is fragile and error prone. Its a fundamental requirement which should block accidental mis-interpretations and unintended dependencies.

lfraleigh commented 2 years ago

This just impacted the ServiceBus package as well. They had to release a bug fix and that release was not marked as deprecated automatically. https://www.nuget.org/packages/Microsoft.Azure.ServiceBus/5.2.0

chrisraygill commented 2 years ago

I would really like this experience to be exposed in the in UI. @loic-sharma can validate these with numbers, but I have the following hypotheses:

  1. When using the deprecation flow, most users want to deprecate all versions of their package, not a specific subset of versions. In other words, the most common goal with deprecation is to deprecate on the id level, not version level.
  2. When using the deprecation flow to deprecate all versions of a package, users can get confused and accidentally only deprecate the latest version of the package since it's the default selection.
  3. When pushing patches to deprecated packages, users forget to deprecate the newly uploaded patch which essentially removes deprecation indicators in search. (The original problem that led to this issue)

My proposal is that we should enable a clear path to deprecating a package on the id level. Doing so should mark all existing versions as deprecated and automatically mark future versions are deprecated.

Here are a couple ideas:

Idea 1 There is selection box outside the version selector that disabled the version selector dropdown. image

Idea 2 There are clear and separate paths for deprecating all current and future versions vs deprecating a subset. image

Behavior notes Id level deprecations (all current and future versions) should be mutually exclusive from subset selection. If you deprecate all current and future versions - then it should override any existing deprecation reasons. Similarly, modifying the deprecation status of an existing version (undeprecating) should remove automatic deprecation of future versions. I can't think of a scenario where one would want to deprecate all future versions, but want specific existing versions undeprecated.

cc @anangaur @jcjiang

Petermarcu commented 2 years ago

I agree with what you are saying @chgill-MSFT ! As @lfraleigh mentioned above, we just had another partner team get bit by this. It would be good to get a near term solution in place to stop the bleeding and then get it wired into all the right UX and defaults.

loic-sharma commented 2 years ago

Thanks for the feedback @Petermarcu! We want to make sure we understand the "north star" user experience so that our engineering MVP aligns to that experience. Like you said, we will first start with a near term solution to unblock our partners. Do let us know if you have concerns with the "north star" UX as that may affect engineering decisions!

scottaddie commented 2 years ago

The ASP.NET team also hit this problem recently with the Microsoft.Extensions.Configuration.AzureKeyVault package. Tagging @Pilchie, as I'm sure he has feedback on how this feature should work.

Pilchie commented 2 years ago

Yes, I agree with @chgill-MSFT here. I think the "All current and future versions"/"Specific versions" radio button would be ideal.