Plan for NuGet in 2022

[JonDouglas]

Today we are excited to share with you the plan for NuGet and NuGet.org. This issue contains summary of the plan for the year and acts as a place for you to leave feedback.

This plan is a collection of input from many stakeholders and outlines where we intend to invest our time in NuGet and NuGet.org.

IMPORTANT
This plan is not a commitment; it will evolve as we continue to learn throughout the release. Some things that are not currently planned for NuGet may get pulled in. Some things currently planned may even be pushed out.

General information

NuGet has a major release following NuGet 6.0 and is currently scheduled for release in November 2022 at the same time as .NET 7.

NuGet will align with the .NET support policy and will therefore not be a long-term support (LTS) release.

NuGet.org does not currently follow any specific schedule and releases features & bug fixes regularly throughout the year.

Breaking changes

NuGet may contain a small number of breaking changes as we continue to evolve NuGet with the .NET platform. Our goal is to minimize breaking changes as much as possible to keep you productive when upgrading.

Themes

The large investments in NuGet are the following themes:

Highly Requested Features

As always, a major input into our planning process comes from votes (👍) for features on GitHub.

These features are areas we are actively engaged in with regards to designing, implementing, and polishing the respective experiences for.

NuGet Tooling

• [PackageReference] Centrally manage NuGet package versions for a solution or a repo #6764
• [Epic]: Central Package Management Improvements for 17.3 #11752
• Design Package Source mapping package installation experiences epic #10730
• Machine readable output for dotnet list package #7752
• support for bulk-updating references into csproj from commandline(s) - dotnet package update #4103
• [Epic] NuGet Package Vulnerability Auditing #8087
• PackRef does not show transitive dependencies - install tab & update tab behavior? #5887
• nuget source password encryption story #1851
• Signing: re-enable signed package verification on Linux and macOS #11262

NuGet Gallery

• Package discovery: Show and search by TFM/package-compatibility  NuGetGallery#3098
• Gallery should show which frameworks a package is compatible with NuGetGallery#4843
• [Feature]: Show and score packages based on popularity, quality, maintenance, and community. NuGetGallery#8964

.NET Platforms and Ecosystem

Much of the work planned for NuGet involves improving the package management experience for .NET across different platforms and ecosystem. This involves work in NuGet to ensure a great experience across .NET technologies.

• Consume pdbs from packages in PackageReference - add Debug Symbols to LockFileTargetLibrary #5926
• Include restoring of symbols in dotnet restore #9667
• Add TFM for .NET nanoFramework #10800
• Nuget restore/package download C# API #10430
• Switch batching method in order to get all build errors from multi-targeted projects #10872

Migrating to .NET

NuGet has always supported many scenarios for package management. In our continued efforts to help you migrate to the latest version of .NET, we will be working on improvements to the Upgrade Assistant and core package management experiences to help you migrate your project to use the latest version of NuGet.

Performance

With each new release of NuGet & Visual Studio comes a plethora of performance improvements when restoring NuGet packages, managing project dependencies, and browsing for the next great package to include in your solution. We will continue to invest time to improve your experiences every .NET & Visual Studio release.

Feedback

Your feedback is important to us. The best way to indicate the importance of an issue is to vote (👍) for that issue on GitHub and Visual Studio Developer Community. We use this data to help us with our regular planning so we can work on the things that matter most to you.

Please comment on this issue if you believe we are missing something that is critical for NuGet, or are focusing on the wrong areas. Give us a little bit of context as to why you believe so and feel free to upvote each other's comments to help us make changes to our future plans.

Huge thanks to @ajcvickers and the Entity Framework Core team for a wonderful format and forum to discuss product plans in OSS. 🎉

[maxkoshevoi]

If you sort issues by upvotes - #3891 comes out on top by the factor of more than two (323 vs 149 votes on the second most voted issue). It has been opened for more than 5 years, and workaround is really flimsy.
Is there some reason of why it isn't addressed yet?

PS: My five cents is that #10850 would be good to fix too. It's not more than a weekly annoyance, but fix doesn't seem difficult

[StingyJack]

@JonDouglas #3050

[JonDouglas]

If you sort issues by upvotes - #3891 comes out on top by the factor of more than two (323 vs 149 votes on the second most voted issue). It has been opened for more than 5 years, and workaround is really flimsy.
Is there some reason of why it isn't addressed yet?

Yes. While we look through all of the top upvoted issues, not every issue is something we can make progress on for a plethora of reasons. We are providing a plan with what items we believe we can significantly make progress on this year with our teams. This doesn't mean that this specific issue will not be considered, just that we had other work we were already engaged on that is also in a similar importance in terms of value from our perspective. I will ensure we consider #3891 in our next planning or if a contribution(proposal or PR) comes through the community, we can consider it earlier.

This is a living roadmap. It will change as we get more feedback like yours. Thank again!

[JonDouglas]

@StingyJack Can you help elaborate on why this issue should be considered? I do not have the context nor time right now to look through this issue, but I will investigate next week. For those reading this comment, please 👍 comments that include additions/subtractions to the roadmap so we know how to better prioritize. Thanks in advance!

[StingyJack]

Can you help elaborate on why this issue should be considered?

@JonDouglas - A 4 part version number is specified in a nuspec, but when the last part is 0, pack truncates that last part making it a 3 part version number. This was done solely as a convenience for nuget.org, without regard for anyone using a different package repo, and without respect for the version number specified. And the nuget team responses were really infuriating because it was clear they did not care what predicament this put customers in.

Ironically it was a breaking change to try to enforce sem ver, but was not given a major version increment.

Using vote count on the OP isnt enough. Issues that have hundreds of comments, and sometimes hundreds more upvotes and downvotes on the comments in the issue need to be taken into account as well. The feedback team uses an expanded scoring system like this. Perhaps you can borrow it.

[ericsampson]

The 4>3 part version normalization did/does create pain for people, such as users of TeamCity and OctopusDeploy (which is a popular combination). I experienced this myself.
Having an opt-in way to disable normalization would be very helpful.