Add End-of-Life (EOL) Status for NuGet Packages #13598
Conversation
|
|
||
| <!-- Why are we doing this? What pain points does this solve? What is the expected outcome? --> | ||
|
|
||
| There are two primary motivations in doing this work. The first being a direct answer to the "am I supported?" question. This is especially prevalent in the .NET ecosystem due to many first-party package providers have robust support policies that require a developer to understand with a decoder ring and too much time on their hands. It should be explictly simple to know you're supported in your current solution so long as your packages do not report EOL. |
There was a problem hiding this comment.
first-party package providers
I don't know what this term means. Are there both first-party and third-party package providers? Perhaps use just "package providers"?
|
LGTM |
|
Thanks for prepping this! Though I think it would be more beneficial to have nuget track "here's when the package goes EOL" rather than "the package is now EOL." That is, when we make package System.Text.Json v9.0.0, we can bake in - at the very beginning - an EOL date of May 12, 2026. One of the complaints that people tell us is that they need to scramble when a package is marked deprecated. Some .NET EOL date hits, we deprecate a bunch of packages, then cause a ton of alerts to be fired off within the company. If instead we made future EOL information available as part of the package metadata, then the internal automated systems could give an appropriate warning window before EOL, which gives a nice low-stress transition period for services to migrate to a newer supported version. Nuget seems like a good vehicle to convey that metadata. You mentioned offline perhaps having your own default policy so that the nuget web site surfaces imminent EOL information when browsing packages. And that seems fine, as long as the raw EOL date is available for consumers who want to apply their own policy instead. Note: When I say "package" here, I mean a specific version of a package. When System.Text.Json v9.0.x. exits support in May 2026, it only affects that version. We wouldn't want the systems to inadvertently treat future major versions of System.Text.Json as EOL on that date. |
|
I think EOL should only mean one thing: this project has reached the end of its life. Don't bother creating issues, and don't expect new releases. If you're starting something new, don't use this. Using EOL to also mean "we don't support version 9.0 anymore, please upgrade to 11!" would be downright confusing. That's my 2 cents. |
|
Based on what @GrabYourPitchforks @amoerie have said, the EOL status sounds good as described in this PR. However, being able to announce deprecation of a package ahead of time by scheduling its deprecation date would be a useful feature! |
I don't understand that argument. Isn't the act of the maintainer logging into nuget.org and marking his packages as no longer supported, exactly how the maintainers can get in close contact with their community? This actually leads me to another issue that is probably more likely to cause EOL: The maintainer isn't around anymore, or completely abandoned the project. The maintainer won't even mark their packages as EOL. Perhaps we need a "Stale" option that packages no longer having any changes for say two years, will get marked stale until the maintainer logs in and marks them "not stale" for another two years. Some email reminders could be sent out to remind them this would happen if they don't "click here". |
|
However this ends up being implemented, with whatever exact definition is adopted for EOL status. It's going to be important that the status is clearly defined. For example have the status text on the nuget.org package link to a docs page defining what the status means precisely and the consequences for those currently using the package and those deciding between packages to adopt. To that end making the status filterable in the nuget.org UI search results, visual studio, the API and other CLI tools would also be important with similar help links for cli output and VS dialog. All in all though a good idea. |
| |-------------|-----------------------------------------|-------------------|----------------------------------------|----------| | ||
| | EOL | No longer maintained or supported | No | Migrate to alternatives | High | | ||
| | Vulnerable | Contains known security vulnerabilities | Possibly | Update or find secure alternatives | High | | ||
| | Deprecated | Not recommended for use | Possibly | Transition to newer packages | Moderate | |
There was a problem hiding this comment.
According to https://learn.microsoft.com/en-us/nuget/nuget-org/deprecate-packages
The "long description" of the legacy deprecation message is "this package is legacy and is no longer maintained".
Therefore, it appears to me that you're adding a new way to do the same thing.
I'm also concerned that even if you intend that deprecate and EOL have different definitions as per the spec, that few people read the docs and in everyday language, deprecated and end of life effectively mean the same thing making it a bit confusing.
There was a problem hiding this comment.
We absolutely do not want to re-invent the wheel here. But I do want to share how people perceive this and our current data (I'll add it into the spec as well):
Here is a quick pulse survey over the last day on how people perceive it as is:
As for data, deprecated w/ legacy is the leading "reason".
I believe we may need to find a clear separation and better flow for these package statuses so they do not come as a surprise to developers. A natural flow might be marking a package deprecated for a specific reason and after a specific timeframe, to mark it end of life to encourage people further to migrate.
I think Levi's comment above touches upon providing users a deprecation window before a package is then EOL'd.
There was a problem hiding this comment.
I can't help coming back to Andy's point: how is Deprecated different from EOL? Would the workflow on https://learn.microsoft.com/en-us/nuget/nuget-org/deprecate-packages be any different for EOL (other than not needing a reason)? And how does this proposal address the motivations differently from the Deprecated status, other than by exposing the state more forcefully in the client?
My main concern is that many of these proposed changes create an implied distinction that EOL is a terminal state, but Deprecated is not (contrary to how it is defined today).
Summarizing and addressing the Motivations:
-
Am I supported? - this is already encompassed in the definition of being Deprecated. While Deprecated only half says "there will be no support or updates", it's pretty clearly a declaration of "use this package at your own risk".
You can deprecate a package if you no longer maintain a package or if would like to encourage your package's consumers to move to another package.
Deprecated is already indicated in some clients (such as VS, as shown in the documentation). It sounds like this proposal would change from a warning triangle to a clearer "stop" signal, which seems to further artificially imply that Deprecated is not EOL.
-
Security - if consumers are not updating Deprecated packages, what will incentivize them by relabeling to EOL? Just by treating it differently on the client? Why not treat Deprecated packages that way on the client? Will "EOL" be regarded differently from "Deprecated" (e.g. in the poll results)?
-
Pre-communicated lifetime (added to incorporate Levi's excellent point) - Can we schedule a package to become Deprecated? Does that reduce the value of a separate EOL state?
To me, the biggest potential value I see proposed here is
A standalone feature also allows for more tailored experiences in the future without being constrained to the existing deprecation framework. As needs evolve for end of life, features can be easily adapted and extended.
However, this seems like "We want to change the deprecation experience, without changing it in situ", but in doing so creates a lot of ambiguity. Is there a concrete scenario that isn't already somehow addressed by Deprecated?
There was a problem hiding this comment.
The core question here is whether the ecosystem has evolved to the point where it needs clearer definitions for these two states:
-
Limited future support, where the package is still usable but not recommended for long-term use (Deprecated).
-
No future support, where the package should no longer be used (End of Life).
I do not see this as a technology problem (i.e. does the technology/capabilities exist, yes, they do), but rather a matter of what definitions people would prefer to see and how they would be emphasized.
There was a problem hiding this comment.
Is there a demand for the limited future support state? (Not doubting, just asking if there's data.) In my limited experience, I've seen planned EOLs ("not supported after {date}"), but never encountered a package with the 3-phase lifecycle described below in the spec (Package created -> package deprecated -> package end of life) where a package has been marked deprecated but not EOL.
There was a problem hiding this comment.
Yep, this ask represents various growing pains of 1P libraries we manage across .NET, Azure, etc. I've also invited other groups to read through this and express their thoughts/pains!
The challenges here is that deprecation today does not encourage the urgency warranted (their words that I also share) and we need to bring more awareness to when packages are deprecated / end of life.
There's a huge shift in security best practices going on and this is a good time to dive into this question further I believe!
There was a problem hiding this comment.
The challenges here is that deprecation today does not encourage the urgency warranted (their words that I also share) and we need to bring more awareness to when packages are deprecated / end of life.
This statement defines a slightly different problem: when deprecation is signaled, it isn't being treated as an urgent priority. Would that be addressed by escalating how deprecation is represented to end users? E.g. if we change from "warning" iconography to "error" iconography (as you've described for EOL), would it make deprecated packages seem more urgent?
There was a problem hiding this comment.
There's a lot to unpack in this topic!
But yes, it could be treated differently if we did certain things! That is definitely an option here. i.e. treat deprecation marked as legacy differently.
There was a problem hiding this comment.
The new EOL state is a good idea, since we're currently overloading the deprecated state to mean two things. Currently, when we want to move an Azure SDK to an EOL state, we have to maintain it for 3 years. During that period, the library is 'deprecated' but still supported. Once those three years are up, we'd like to EOL it, but we're relying on custom messages added to the 'deprecated' state to convey this. The process would be more crisply defined with a separate EOL state we could apply to packages that are outside that 3 year window.
|
|
||
| <!-- Explain the proposal as if it were already implemented and you're teaching it to another person. --> | ||
| <!-- Introduce new concepts, functional designs with real life examples, and low-fidelity mockups or pseudocode to show how this proposal would look. --> | ||
| This functionality will follow the footsteps of the existing deprecation and vulnerability functionality. It will be closest to the deprecation experience today, but will include a way for a package owner to mark a package and its many versions at anytime "EOL". There will be no reason nor custom message to provide to users. However, there will be an suggested alternate package to use to encourage a direct action from the developer. |
There was a problem hiding this comment.
It's unclear to me, does this mean that EOL is intended to be defined at a package ID and therefore apply to all versions of a package, or is EOL like deprecation where each version can be independently togged EOL/not-EOL?
There was a problem hiding this comment.
If EOL, possible to have "Recommended" alternatives?
There was a problem hiding this comment.
It's unclear to me, does this mean that EOL is intended to be defined at a package ID and therefore apply to all versions of a package, or is EOL like deprecation where each version can be independently togged EOL/not-EOL?
Defined similarly to deprecation at the per-version level.
If EOL, possible to have "Recommended" alternatives?
Yes, suggested alternatives are utilized today and EOL could suggest new versions of the same package or another package ID + version entirely.
There was a problem hiding this comment.
Defined similarly to deprecation at the per-version level.
In that case, I think we need to have more of a think of the technical considerations and what the acceptable perf impact will be for the part of this spec that says we should warn at restore time. I get that this is intended to be a CX spec, or non-technical spec, but given the similarily to NuGetAudit and vulnerability reporting, we already know information that is relevant.
For NuGetAudit, the 90th percentile for loading the vulnerability database is 500 milliseconds, the 95th percentile is 1.4 seconds, and the 99th percentile is over 5.5 seconds. We already know that deprecation data on nuget.org is at least an order of magnitude larger than the amount of vulnerability data, so we can expect that the customers already having bad performance to have a much worse time if we add EOL and deprecation warnings at restore time.
The VS perf team also say that our vulnerability database is causing measurable impact on memory usage. This is of course something that can be solved/improved before this new EOL (or deprecation warnings during restore) is implemented. But I want to make it clear that it's not a simple case of "do it the same way that NuGetAudit does vulnerabilities". We have to find a better approach for implementation.
If EOL information was only at the package ID level, not specific versions, yes it will be less useful to package authors who want to only support specific branches (major/minor versions), but it will be much more technically feasible from a performance point of view.
There was a problem hiding this comment.
I wonder if we're leaning in the https://xkcd.com/927/ direction.
Conceptually, I think it is less likely cause confusion as a variation to deprecation, rather than a completely separate.
If I read the docs and read about deprecation first and then EOL later, I feel like I'd have questions about which one to use in which scenario. We should aim to simplify that decision.
There was a problem hiding this comment.
I also echo Andy's concerns about the technical considerations for this.
Ideally we would focus on the concepts of course and try to figure out the technical side later, but I feel like with us having a better understanding the challenges with deprecation, we probably shouldn't commit to restore warnings immediately.
|
What do you think of letting the package author add a note like "This is no longer needed because X" or "Update to the new package name Y" or "Find an alternative package" or "See explanation at https://myblog/"? Without this it could be a bit confusing or even frustrating to someone when a package they depend on (or something they are trying to install because it's referenced from a tutorial or similar) is now saying it's EOL, but they have no idea whether there's an alternative, whether the developer has abandoned it, or whether it was killed by Microsoft due to security or legal concerns, or whatever.
I guess that would cover it. I'm just thinking of a single string you can add when marking something as EOL, and showing it on attempted restore. |
The former part was mostly talking about the registry's responsibility. We get a lot of asks about doing certain things or knowing about certain statuses of things. We don't have the insight to do that at scale and rely on the community. I believe a stale community reporting mechanism would be useful, but I don't think there's any need to have a package author do anything but mark their packages appropriately when the time comes. |
We support this today via 
https://www.nuget.org/packages/Microsoft.Rest.ClientRuntime.Azure |
| <!-- What parts of the proposal need to be resolved before the proposal is stabilized? --> | ||
| <!-- What related issues would you consider out of scope for this proposal but can be addressed in the future? --> | ||
| - Is this a unique enough experience to consider being a standalone package status? | ||
| - Is end of life (EOL) the proper terminology? |
There was a problem hiding this comment.
That is a tricky question and was also commented by @zivkan above.
On my first reading of this I didn't think "Deprecated" and "EOL" were distinct concepts, and then after I realised they are, I thought the terminology was problematic because the words themselves don't innately have different meanings that you can assume people will understand. Either one of them might be assumed to come earlier in the lifecycle than the other, or they might be assumed to mean the same thing.
However I don't immediately have a better suggestion. I thought of "Withdrawn" or "DoNotUse" but they both need clarification too. Perhaps if the clients show some kind of "What does this mean?" link next to any non-good status, and that goes to a page depicting the lifecycle, that would be understandable enough.
There was a problem hiding this comment.
Someone suggested a "traffic light" metaphor which I really liked:
🟢 Green: No status or issues. The package is safe to use.
🟡 Yellow: The package has deprecation warnings or low-moderate severity vulnerabilities. Caution is advised. Update or replace soon.
🔴 Red: The package is at end-of-life or has high-critical severity vulnerabilities. Update or replace ASAP.
Of course, these policies are entirely up to the consumer, but a mental model to use to demonstrate the "lifecycle" and what this proposal hopes to help define further.
There was a problem hiding this comment.
Here's a doc I like on EOL. It's more about communication in general, but provides insight into how we might need to communicate the topics being discussed here.
There was a problem hiding this comment.
How about a new category of deprecation called EOL?
I think by tying it to the current deprecation concept, we stand a chance at being able to "reuse" some of the currently deprecated packages and reframe them as EOL (Example, all package versions are deprecated, no alternate package was provided).
With a completely new concept, the EOL concept adoption will require that author do more work on their packages.
|
|
||
| There are two primary motivations in doing this work. The first being a direct answer to the "am I supported?" question. This is especially prevalent in the .NET ecosystem due to many first-party package providers have robust support policies that require a developer to understand with a decoder ring and too much time on their hands. It should be explictly simple to know you're supported in your current solution so long as your packages do not report EOL. | ||
|
|
||
| The second primary motivation is security. Being on unsupported packages that are EOL is a high risk as there will be no security updates and may render your application vulnerable. A typical lifecycle of an end of life package may accrue known vulnerabilities over the years as they are discovered which may add additional risk for developer teams to sincerely consider prompt remediation. |
There was a problem hiding this comment.
I feel like this is still a maintainability consideration.
A functional bug and a security bug are both potential blockers for usage.
We also do have mechanisms for both marking a package as no longer recommend (deprecated) and as having a security risk (vulnerable).
|
|
||
| <!-- Explain the proposal as if it were already implemented and you're teaching it to another person. --> | ||
| <!-- Introduce new concepts, functional designs with real life examples, and low-fidelity mockups or pseudocode to show how this proposal would look. --> | ||
| This functionality will follow the footsteps of the existing deprecation and vulnerability functionality. It will be closest to the deprecation experience today, but will include a way for a package owner to mark a package and its many versions at anytime "EOL". There will be no reason nor custom message to provide to users. However, there will be an suggested alternate package to use to encourage a direct action from the developer. |
There was a problem hiding this comment.
I wonder if we're leaning in the https://xkcd.com/927/ direction.
Conceptually, I think it is less likely cause confusion as a variation to deprecation, rather than a completely separate.
If I read the docs and read about deprecation first and then EOL later, I feel like I'd have questions about which one to use in which scenario. We should aim to simplify that decision.
|
|
||
| <!-- Explain the proposal as if it were already implemented and you're teaching it to another person. --> | ||
| <!-- Introduce new concepts, functional designs with real life examples, and low-fidelity mockups or pseudocode to show how this proposal would look. --> | ||
| This functionality will follow the footsteps of the existing deprecation and vulnerability functionality. It will be closest to the deprecation experience today, but will include a way for a package owner to mark a package and its many versions at anytime "EOL". There will be no reason nor custom message to provide to users. However, there will be an suggested alternate package to use to encourage a direct action from the developer. |
There was a problem hiding this comment.
I also echo Andy's concerns about the technical considerations for this.
Ideally we would focus on the concepts of course and try to figure out the technical side later, but I feel like with us having a better understanding the challenges with deprecation, we probably shouldn't commit to restore warnings immediately.
|
|
||
| Introducing a concept of **"end of life"** will make it clear to package authors that these packages are not intended to be used any further as they are no longer supported, will not receive critical updates, and feedback will not be considered. This would be a new definition including: | ||
|
|
||
| - End of life (EOL) - Indicates the package is no longer maintained, supported, or updated by its authors. |
There was a problem hiding this comment.
The difference between "no longer maintained" and "updated by its authors" isn't super clear to me. I suggest instead using your previous wording of "no longer supported, will not receive critical updates, and feedback will not be considered".
| | Status | Definition | Updates Available | User Guidance | Risk | | ||
| |-------------|-----------------------------------------|-------------------|----------------------------------------|----------| | ||
| | EOL | No longer maintained or supported | No | Migrate to alternatives | High | | ||
| | Vulnerable | Contains known security vulnerabilities | Possibly | Update or find secure alternatives | High | |
There was a problem hiding this comment.
For the Vulnerable status, we need to clarify this Risk value is different than the Severity value of the associated CVE. Example here where the CVE has a severity of moderate:
There was a problem hiding this comment.
Yeah these are separate categories of risk and relative to the policy of the consumer. I was just trying to convey the idea that Vulnerable and EOL risk is high compared to other package statuses.
|
|
||
| When a package is marked EOL, a few things will happen: | ||
|
|
||
| - The package at restore time will appear with a new warning letting any consumers know the package is EOL. |
There was a problem hiding this comment.
As a default behavior, a warning may suffice. I can imagine some customers wanting package restoration of EOL packages to produce errors instead, to force breaking of builds.
There was a problem hiding this comment.
These warnings tend to break people due to them enabling TreatWarningsAsErrors, but definitely agreed it should suffice.
| - The package at restore time will appear with a new warning letting any consumers know the package is EOL. | ||
| - The package on NuGet.org and throughout browsing experiences will show a label or affordance mentioning its EOL status. | ||
| - The package on NuGet.org API can be queried for the EOL package status for any tooling to build upon this. | ||
| - The dotnet CLI will have a list command to show all EOL packages. |
There was a problem hiding this comment.
How can we accommodate customers who want to suppress the display of EOL packages from the configured package feeds? It could be a nice way to prevent installation of them. Imagine a nuget.config file placed at the root of the project repository with a setting that enables this behavior. Any dev working on that project won't see EOL packages when browsing configured package feeds.
There was a problem hiding this comment.
Ideally they can just disable auditing type flags within their project similar to what vulnerability provides today
| ## Future Possibilities | ||
|
|
||
| <!-- What future possibilities can you think of that this proposal would help with? --> | ||
| - Integration with security tools to automatically flag EOL packages in dependency graphs. |
There was a problem hiding this comment.
Is Dependabot one such security tool to look at? What about generating Component Governance alerts too?
There was a problem hiding this comment.
Yep, this metadata could absolutely be used by whatever tooling to help users understand their risk.
|
We don't understand why we need a new EOL status when we have Deprecated status. Is this just a visual change in NuGet.org? Something else. |
|
Great discussion so far. Thanks for raising this proposal, @JonDouglas 👏.
I agree with @aortiz-msft (and others like @zivkan who raised similar questions). To me, the only benefit of having EOL as a separate concept from Deprecation would be to make EOL an ID-level property (deprecation is version level). Other new ideas called out in the discussion could all be bolted on to the existing deprecation model, it seems. And EOL at the ID level doesn't make sense. .NET team couldn't use it for older versions of framework packages associated with EOL .NET versions, assuming the ID is still used for newer .NET versions. Questions from me:
If we had just named "deprecation" as "package life cycle", then EOL would have clearly fit into the bucket 😄. |
|
Thanks for the writeup, @JonDouglas.
|
This is an interesting state, but almost sounds like it would be useful for indicating that a project is "complete". Not necessarily a severe or urgent need to replace, but no longer maintained. It might not even be deprecated (IMO deprecated means "use something else", but this is a viable scenario where there isn't a replacement). In other words, is there a viable lifecycle of |
|
|
||
| <!-- Explain the proposal as if it were already implemented and you're teaching it to another person. --> | ||
| <!-- Introduce new concepts, functional designs with real life examples, and low-fidelity mockups or pseudocode to show how this proposal would look. --> | ||
| This functionality will follow the footsteps of the existing deprecation and vulnerability functionality. It will be closest to the deprecation experience today, but will include a way for a package owner to mark a package and its many versions at anytime "EOL". There will be no reason nor custom message to provide to users. However, there will be an suggested alternate package to use to encourage a direct action from the developer. |
There was a problem hiding this comment.
We (Azure SDK team) need a way to convey extra information to users via a custom message for EOL packages. Specifically, we often provide migration guides for users to follow when moving off the deprecated/EOL package to the recommended replacement. We're currently providing that information via a custom message.
|
Hi folks, Thank you so much for the great discussion on the direction of this proposal. I'm going to take some time to try to address the concerns, but first will re-iterate them here.
Here are some answers from my perspective trying to connect everyone's ideas thus far. Please feel free to build upon these and debate!
The definition is loaded. There is ample evidence to suggest this on the consumer and publisher side. I am proposing a new definition to clearer separate what these terms mean. Going back to #13598 (comment) the metaphor of a stoplight may help show this perspective: 🟢 Green: No status or issues. The package is safe to use.
No. They mean different things even today. Deprecation still implies a slow transition due to legacy reasons. EOL implies an immediate transition due to lifecycle. If deprecation had a "lifecycle" reason or an "other" reason marked as lifecycle, it could imply a similar meaning, but this would still sit in a "caution"/🟡 category rather than an immediate action/🔴 one.
None of these states are "terminal" per-say. You can update their statuses to reflect your business needs. If you need to un-deprecate or un-EOL something for whatever rare reason, that is your choice to communicate with your users. Flexibility is key and desired in many of these cases.
Performance is definitely a challenge here as noted in previous specifications to add deprecation metadata at restore time when we did the auditing work. https://github.com/NuGet/Home/blob/dev/accepted/2022/vulnerabilities-in-restore.md#surfacing-deprecation-information we will have to work through these challenges given it is the right thing to add to the product based on further signal. So far, the direction has suggested people would like to see more of this, not less.
I initially removed custom messages as a decision to be more direct on how users should migrate to the suggested package. With further feedback, it seems that we may need to consider keeping this so users have a definitive way of getting the last proper communication of the lifecycle. Thanks to @mario-guerra for that feedback. For pre-announcing deprecation dates, this would fall into marking the package as deprecated w/ a similar custom message stating how long the deprecation will be until it is marked EOL. You can think of it like this. Supported -> Deprecated (w/ message to deprecation communication) -> EOL (w/ message to EOL communication) Here's a practical example assuming this was implemented already: .NET 6 packages released Nov 2021 🟢 -> Mark it deprecated 1 year ahead of EOL in Nov 2023 🟡 -> Mark it EOL in Nov 2024 🔴.
No. This proposal does not cover that. Another proposal of community reports marking packages "stale" could cover this.
It is my hope that if we have a clearer separation of definitions and visual aides, that everyone will understand these perceived risks in a straight-forward fashion. Today much of this risk is invisible to users beyond warning triangles Again, this is my perspective on tackling a handful of challenges I've experienced over the last few years and what this solution could bring into the mix. |
While I like that flow in general, I think that a full year of deprecation warnings is too much. If you work in a company which only updates from LTS to LTS versions of .NET, you'd get deprecation warnings immediately when the next LTS version is released. So you have no time to update before getting warnings. I think 6 months would be more reasonable. |
|
Wouldn't marking package as "deprecated" with reason set to "other" cover the use case of that transitional state (with custom message potentially indicating the EOL) and then re-deprecating it as "legacy" effectively achieve that 3-phase lifecycle? It seems like there is a need to clarify the deprecation options and maybe their messaging in UX. And probably adding a feature to schedule deprecation state into the future. |
|
We should also consider the capability of auto-promoting a deprecated status to EOL status after a configurable amount of time or date. |
This pull request introduces a new status for NuGet packages: End-of-Life (EOL). The EOL status indicates that a package is no longer maintained, supported, or updated by its authors. This status aims to provide clear guidance to package consumers and improve security by highlighting unsupported packages that should be migrated to alternatives.
Rendered Proposal
Key features:
By implementing the EOL status, developers will have better visibility into the support lifecycle of their dependencies, allowing for more informed decisions and enhanced security practices.
Related: NuGet/NuGetGallery#9638 & NuGet/NuGetGallery#9837
Please 👍 or 👎 this comment to help us with the direction of this feature & leave as much feedback/questions/concerns as you'd like on this issue itself and we will get back to you shortly.
Thank You 🎉