Open loic-sharma opened 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.
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
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:
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.
Idea 2
There are clear and separate paths for deprecating all current and future versions vs deprecating a subset.
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
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.
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!
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.
Yes, I agree with @chgill-MSFT here. I think the "All current and future versions"/"Specific versions" radio button would be ideal.
Related Problem
Imagine my package
Old
has been replaced byNew
. I still supportOld
and upload new versions to fix security issues. Since I want all my customers to move toNew
, I deprecate all versions ofOld
.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