Repository navigation
Plan for NuGet in 2022 #11571
Description
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. 🎉
Activity
maxkoshevoi commentedon Mar 24, 2022
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 commentedon Mar 26, 2022
@JonDouglas #3050
JonDouglas commentedon Mar 26, 2022
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 commentedon Mar 26, 2022
@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 commentedon Mar 26, 2022
@JonDouglas - A 4 part version number is specified in a nuspec, but when the last part is 0,
packtruncates 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 commentedon Mar 29, 2022
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.
StingyJack commentedon Sep 4, 2022
@JonDouglas Something not explicit on this list but that is incredibly important is to better separate things that are important for NuGet.org policy and things that are important for NuGet. There should not be any changes made to NuGet that are done for the sole purpose of satisfying a policy for NuGet.org. There are many other package feeds that exist that repeatedly get crippled and functionality lost due to the nuget.org policy leaking into the package manager code. Examples of this would be the removal of the PS1 scripts - a liability concern for Nuget.org, but not necessarily for private feeds. We should retain the right to choose, the nuget team can not make the correct decision for our private feeds. The unwanted package version number changes mentioned previously are another change that was made for nuget.org but forced on those that did not want or ask for it.
clairernovotny commentedon Sep 15, 2022
@StingyJack The removal of PS1 scripts has more to do with client security and the way packages are added/removed than anything to do with NuGet.org. With SDK-style projects, there's no consistent "install" gesture where a script can be reliably run. It also is a security issue as scripts from packages run as your user context and can do anything you can do.
StingyJack commentedon Sep 16, 2022
@clairernovotny - And in our private feed, that we put our packages in, and consume within our organization, running a script or xdt transform to automate manual tasks is desired and useful. On public feeds like NuGet.org I can understand why you dont want the headache of being held liable for a bad package, but you didnt need to take away something useful from us because you were worried about what someone could do with it on your site.
That's a joke, right?
dotnet add package Newtonsoft.JsonThese seem like fine installation "gestures"
So does the program that I am going to start debugging once the package is installed.
qubitz commentedon Dec 10, 2022
Glad to have found this roadmap. I was initially worried not finding it on The NuGet Blog, though this is a better location.
I am 11 months old to this party, but wanted to throw #5553's hat in the ring. Potentially for next year, time/contributions allowing. It has the second most amount of 👍s at 132.
Although the issue has been discussed over the course of 5 years, there has been a lot of noise. Some effort to research the root of the issue and draft a solution would show good progress to the community.
JonDouglas commentedon Jan 20, 2023
We are closing this issue in preparation of publishing a plan for 2023. Thank you all for a great 2022! Please help us with feedback when we post the plan in a couple weeks for 2023!