Open richlander opened 9 months ago
I'm not sure if it's best for this issue or not, but the support table can be improved in more ways.
Today it's completely calculated. Calculation is good since it will help predict what NuGet behavior will be, but it doesn't allow for a package to control that.
Sometimes a package might add a targets file specifically to say it's not supported somewhere. Ideally there would be a way to represent that in this gallery UI. Today since the package would install there it looks like it's supported which is the opposite of what we'd want.
Another case is a package that wants to represent that it's no longer needed on a framework. We don't have the ability for frameworks to represent this, but maybe the package could - at least in this visualization.
Great topic. Do you have an example package that demonstrates that use case?
cc @JonDouglas
This is my perspective here, not the teams as I helped drive majority of this work circa 2021-2022.
The work is focused on a customer problem of compatibility. Many users we interviewed were using out of support versions of .NET and they use NuGet.org to help them understand what packages that are "compatible" w/ their current constraints and the task they're trying to accomplish. In other words, their definition was largely "will it install and can I use it?".
I think EOL is a good idea, and it requires work that I'm not sure NuGet is the only team involved in providing such an experience. In my head, an API would be provided by .NET for all tooling to consume to check for "unsupported TFMs" which tailors many experiences further.
There are other initiatives going on too such as warning consumers using certain outdated TFMs like < .NETStandard2.0:
https://github.com/dotnet/designs/pull/317
While I'm not fully aware of the full "out of support" story in CLI / IDEs as I don't think there is much of one, I would personally think that would be the right place to tackle EOL and have it trickle to these cross-cutting experiences as well. For example, this experience could simply not show any TFMs that are deemed "out of support" and/or provide a toggle that shows the current experience if users accept they are "out of support" i.e. "show unsupported".
I think at the end of the day, discouraging use of unsupported TFMs is important and requires a proper flow of this information. That's my naive perspective here and would love to learn more about unsupported initiatives if there are any more!
Related issue: https://github.com/NuGet/NuGetGallery/issues/10196
Related Problem
Compatible frameworks are displayed as all equal. We choose to highlight targets that happen to be included in the package. We should highlight (or lowlight) targets that are EOL.
The Nuget.Packaging package make this problem particularly obvious. The highlighted .NET version is an EOL one. That's very odd.
The Elevator Pitch
Make it easier for customers to know that their usage might be concerning.
Additional Context and Details
https://github.com/NuGet/NuGetGallery/pull/9835