NuGetGallery
NuGetGallery copied to clipboard
NuGet
[Feature]: Change Target Framework Badges to be Latest instead of Lowest.
Related Problem
No response
The Elevator Pitch
When we started this work for Framework badges we had a decision to make of whether to do something familiar for package users in terms of providing them the lowest framework asset in the package or the highest.
We initially went with the lowest framework asset as that was the common practice with .NET & NuGet and would adjust based on feedback.
Now with further feedback, I believe we should re-consider this to be the latest asset to show how up-to-date the package actually is as it may make more sense long term for a consumer to see a package continues to provide support for the latest version of .NET.
TL;DR - Display the latest TFM included rather than the lowest.
Related and can be ignored if we do this work instead: https://github.com/NuGet/NuGetGallery/issues/9044
Additional Context and Details
No response
Is there a community understanding about adopting new TFMs just to show "up-to-dateness"? I often see some package authors mention that they follow oldest supported LTS, and only add/update new TFMs if there is a specific new runtime features (e.g. if package targets .NET 8, they will only update to .NET 9 if there's a new feature in .NET 9), or when their current version goes out of support (e.g. updating .NET 6 to .NET 8 only after .NET 6 goes out of support in Nov 2024).
This also aligns with my understanding that .NET assemblies are generally forward compatible - a .NET X assembly will generally work fine in .NET X+1, X+2, etc. So there isn't generally an incentive to add multitargeting overhead unless necessary to take advantage of new features or address breaking changes.
Implying that "latest TFM" is a signal of up-to-date hasn't been necessary by precedent. Will it visually penalize projects that have no technical need to adopt every a TFM as soon as they are released? Will it incur overhead to projects that need to add more complicated build infrastructure to multitarget their solutions?
You bring up excellent points which are basically the discussions we had prior. Here's one perspective from me surveying and talking to many developers and authors about:
From the consumer perspective people actually look at the date of a package being updated last. A close extension of that is seeing that a package also supports the latest version of .NET.
From the author perspective many packages have little need to support the latest version, but many do this within a year or so of a major release. Some choose to not do it either.
There is no penalty here. It is all just about how to best present it to the world. We are slowly moving to a cadence where many popular packages support the latest version around November and many add support within the following year till the next release.
When I'm at work again I will share some adoption graphs similar to this Twitter post:
https://x.com/nuget/status/1702405680416645175?s=46
TL;DR targeting net6 doesn't mean a package isn't "up to date" or that it can't be used on newer frameworks. It just specifies what the lowest framework is that it's supported on.
I would +1 that we shouldn't be encouraging the unnecessary busywork of updating target frameworks in packages just because users haven't been educated on forward compatibility.
The preferable option would be to indicate that a package targeting a specific framework (like net6 or net462) is support on that version as well as on newer versions of those frameworks.
targeting net6.0 would be considered out of date in a month though. net7.0 is already out of support, net8.0 is what is LTS.
There's a difference between a package supporting a framework (the minimum runtime "interface" it requires) and Microsoft supporting a runtime.
If someone decides to continue using net6 (or net5 or netcoreapp2.2) even though the runtime is out of support, then there's nothing wrong with a package continuing to advertise what the minimum runtime is that it is supported to run under.
This misconception that a package minimum TFM means that it can't work on newer runtimes (which it can) is the reason I'm arguing against the change proposed in this issue.
Could we have a Twitter poll and customer research on this?
I already included the bits in the description. This work is ready to go do.