Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
dotnet pack does not support title in .csproj #4150
I think we should only phase this out after we have phased it out of all user experiences. In particular, nuget.org shows title in search results, so this is a very visible field. I did some analysis of the top 100 packages on nuget.org.
Exact match means the ID and title are exactly the same.
If more than half of our top packages are using title, we shouldn't eliminate it from tooling.
i feel like what we are doing is a good first step..we continue to support title (and summary) in the following sccenarios :
The scenario for which we are eliminating it is:
People who want a mix of both worlds can use the intermediate generated nuspec file from their package referenced based projects and pack the nuspec with the title added to get the desired result.
This way we discourage people from using Title and make them follow the recommended convention of having ID the same as Title, but not essentially blocking anyone.
The problem is that we have no telemetry or idea of how frequently users are packing .nuspec vs packing .csproj today. If we found that more than half of our users are using a feature, aren't we inadvertently discouraging users from moving to the new world if it doesn't have that feature?
Suppose we are designing the migration flow from packages.config to package reference. How would that migration work if the client has a package title?
Is this a well documented or polished experience? Are there basic knobs and switches that can be used so that customers don't have to make XML munging code on the intermediate .nuspec? If you are used to packing a legacy .csproj, is the "new world" going to be a lot more painful if you just want to set your package title?
I guess it seems strange to me to eliminate commonly used field when we a) have no documented high level design to phase out package title and b) the cost of implementing package title in package reference is very low.
Just spit-balling here, but the phase-out plan could be:
changed the title from
dotnet pack does not support title attribute in .csproj
dotnet pack does not support title and summary attribute in .csproj
Jan 23, 2017
I'm not sure Title should be phased out at all. There needs to be something other than package id that shows what the package is and give it a friendly name. This is a regression from
All of Rx.NET does this.
Package Id: System.Reactive, Title: Reactive Extensions (Rx) - Main Library
Title needs to be a first-class experience and cannot be phased out. Package Id is simply not enough.
Ever since Title stopped being the main result in the NuGet Package manager things have gotten really confusing. Often my package IDs are short or legacy such as "Xam.Plugin.Connectivity" when the Title is "Connectivity Plugin for Xamarin", which is what makes sense. The UI should simply just show the title and the package name under it. Seems like an extremely easy improvement.