Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support package renames #7896

Open
10 of 17 tasks
loic-sharma opened this issue Mar 23, 2020 · 9 comments
Open
10 of 17 tasks

Support package renames #7896

loic-sharma opened this issue Mar 23, 2020 · 9 comments

Comments

@loic-sharma
Copy link
Contributor

loic-sharma commented Mar 23, 2020

Background

Spec: Support package renames

Tasks

Minimum Viable Product

These are the highest priority work items. Once they are complete, we will have an internal MVP that our partner team can use to give feedback:

A/B test

Next we can A/B test the popularity transfers on PROD to ensure the new search rankings does not regress customer scenarios:

General Release

Once we feel confident that the feature addresses the needs of our internal partner, we can work on releasing this feature to all customers.

Add Gallery UI:

Testing:

Future Refinements

Once the feature has been released to all customers, we can consider the following future refinements. These are low priority:

Recently Triaged Issues

All issues in this section should be triaged by the v-team into one of their business objectives or features.

@loic-sharma loic-sharma changed the title Improve package renames Support package renames Apr 13, 2020
@Nirmal4G
Copy link

Also introduce a concept of Package family by namespaces.

for eg.: All NuGet.* packages by NuGet fall under NuGet family but 3rd party NuGet.* packages can listed under the same home but under 3rd party packages!!

@loic-sharma
Copy link
Contributor Author

Thanks for the suggestion @Nirmal4G! NuGet.org has package ID prefix reservation that I think may already address this concern. For example, the NuGet. package ID prefix is reserved to the nuget account. As a result, NuGet.* packages owned by nuget account (like NuGet.Packaging) have a blue checkmark. NuGet.* packages not owned by nuget (like NuGet.Build.Packaging) do not have this blue checkmark. I hope that help!

@Nirmal4G
Copy link

ID prefix verifies who owns the prefix and not answering the question Are there any alternatives or different functionalities based on NuGet by 3rd parties available?

My solution answers to that. Basically 3rd party packages visibility. There are great solutions available by 3rd parties but they are not searchable much.

@loic-sharma
Copy link
Contributor Author

loic-sharma commented Apr 21, 2020

I see. Maybe additional search filters on the owner and verified status could help. Thanks for the feedback!

@Nirmal4G
Copy link

Nirmal4G commented Apr 21, 2020

I tried using NuGet search syntax. I can't exclude NuGet packages by NuGet owner.

Do we have -owner:nuget syntax for exclusion?
Update: Seems this https://nuget.org/packages?q=nuget+-author:nuget+-owner:nuget is not working.

@loic-sharma
Copy link
Contributor Author

We don't have any exclusion syntax today, no.

I'm curious, what kind of packages would you like to find? Would you like to find packages that "extend" functionality provided by NuGet.* packages? Would a "reverse dependency" feature help? See: https://github.com/NuGet/Home/wiki/Reverse-Dependencies-(Dependent-Packages)

@Nirmal4G
Copy link

Nirmal4G commented Apr 21, 2020

Not just for NuGet but for any other package that has an extended 3rd party solution. NuGetizer-3000 was hard find. If Miguel didn't tweet that, I wouldn't have found it, just by browsing through github/nuget.

Some packages like MSBuild tools and SDKs don't have dependencies, since they are self contained packages. Those are hard to find. Though the new PackageType filter in the search help but not for regular packages and those which don't specify the packageType.

@clairernovotny
Copy link
Contributor

Does this feature address the diamond dependency issue?

A core problem is that renaming a package will cause conflicts in a graph containing packages that reference the new name and ones that reference the old name. Assuming that the namespaces in assemblies in the package can't be changed, this will cause lots of conflicts that are unsolvable by the end user.

@loic-sharma
Copy link
Contributor Author

loic-sharma commented Jul 2, 2020

After talking to internal partners we have decided to abandon the "package renames" feature. We believe it would be better to improve the package deprecation feature instead.

We will keep the popularity transfer feature and will allow customers to apply using a process similar to our Package Id prefix reservation process. This work is tracked by #7943.

/cc @chgill-MSFT

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants