When you publish an update for Microsoft.ApplicationInsights.Profiler.AspNetCore, don't mark the previous version as deprecated immediately #217
KirkMunroSagent
started this conversation in
Ideas
Replies: 1 comment
-
|
See response in #219. Thanks! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
This idea comes from the perspective of someone who does package management.
Whenever a new Microsoft.ApplicationInsights.Profiler.AspNetCore package is published, whoever publishes that package also marks the previous version as deprecated. This is different behavior than what is done on any other Microsoft.* nupkg. The challenge is that when you mark the previous version of Microsoft.ApplicationInsights.Profiler.AspNetCore as deprecated, it causes a little warning sign to appear in the NuGet Package Manager UI in Visual Studio, because suddenly projects are using a deprecated version of a package. That warning is not appropriate, because projects are fine to continue using the previous version, at least for a while.
The problem with this approach is that it masks nupkgs that really need attention. For example, if a package is found to have a known vulnerability, but that vulnerability is not very severe, a warning icon can show up in the Nuget Package Manager UI in Visual Studio. That is something that really should be getting the attention of a package manager, because they need to look into the warning details so that they can triage the package update appropriately. When a new version of Microsoft.ApplicationInsights.Profiler.AspNetCore is published, by marking the previous version as deprecated, you are potentially masking real warnings that need attention. Imagine if every product team that published NuGet packages marked all of their old versions as deprecated. Suddenly we'd have warnings on every package all of the time, making those warnings absolutely useless.
All to say, by marking a previous version as deprecated when you publish a new package, you are taking the wrong approach because it sets the expectation that the package needs attention right away, which is not the case. Please change your publishing strategy such that you only mark an old version as deprecated if it is truly not expected to work anymore.
Beta Was this translation helpful? Give feedback.
All reactions