Support redirecting manifests

[denelon]

Description of the new feature / enhancement

Sometimes a package id gets changed. Usually this happens when the publisher changes, or when the community has determined a better approach for organizing manifests. When this happens, users who have packages.json files could be broken, and the install of those packages that have been moved will fail.

Proposed technical implementation details

Current thinking is that we would leverage a new YAML file "Redirect.yaml". This file would be placed in the package directory (as opposed to the version directories) as a signal that the package has been moved. The client would be able to understand what to install.

Examples:

Foo.Bar has been redirected to Contoso.Bar

winget install Foo.Bar would inform the user that the package has been redirected to Contoso.Bar, and Contoso..Bar would be installed.

>winget install Foo.Bar
Found Bar [Foo.Bar]. The package has been redirected to Bar [Contoso.Bar].
Found Bar [Contoso.Bar] Version 2.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://www.contoso.com/bar.exe
  ██████████████████████████████  1.77 MB / 1.77 MB
Successfully verified installer hash
Starting package install...
Successfully installed

---

winget upgrade Foo.Bar Upgrading a package that has been redirected.

>winget upgrade Foo.Bar
Found Bar [Foo.Bar]. The package has been redirected to Bar [Contoso.Bar]. 
Found Bar [Contoso.Bar] Version 2.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://www.contoso.com/bar.exe
  ██████████████████████████████  1.77 MB / 1.77 MB
Successfully verified installer hash
Starting package install...
Successfully installed

---

If a user were to perform a search, the "old" package would not be displayed by default.

winget search -e --id Foo.Bar - No package found

>winget search Foo.Bar
"No package found matching input criteria."

winget search -e --id Foo.Bar --includeRedirected - Foo.Bar is found and has been redirected to Contoso.Bar

The UX for displaying redirected packages may not fit well in the current table format. Suggestions are welcome.

---

Settings would be added to change default behavior.

"searchFilters": {
  "redirectedPackages": "include"
}

The default behavior would be to exclude.

[Trenly]

Discussion merged from #1513

---

There is also a need to support "optional" or "conditional" redirects here.

Some programs have multiple versions where a newer version replaces an older version, but both packages are maintained separately. One example of this would be Corsair.iCUE.3 and Corsair.iCUE.4, where they are two separate packages but iCUE.3 is replaced by iCUE.4. Corsair still maintains and provides updates to the 3.xx application to support older devices that are still on the market. Corsair.iCUE.3, is still available in the community repository, and will install without issue. Corsair also provides a newer version of the same software in their 4.xx application. The 4.xx software will install over and remove the 3.xx software, but the 3.xx software will not automatically upgrade to the 4.xx software

Side note: This is the reason they were split into separate packages in the first place, since the PackageName is different, anyone with the 3.xx software wouldn’t see the 4.xx versions even when they were under the same package identifier

Additionally, some open source software that is no longer maintained may be picked up by a different user and published under a different package name. Another developer may create their own fork of the project, and continue development. In this case, since its a new publisher, there would be PublisherA.Package and PublisherB.Package. Now, these packages would be functionally the same for the same versions, but PublisherB would have newer versions available. In this case, a user may want to be informed that the package from PublisherA is “replaced by” the package from PublisherB, since it is the same application but under a new developer or fork

---

From a user perspective, @denlon provided these stories -

• I would be sad if I needed 3.x and mistakenly upgrade to 4.x and my stuff broke.
• I would also be sad if 4.x suited my needs better and I wasn't informed.

[cjwijtmans]

just look at how gentoo does it. very well. You can install a specific major version and it will update minor version just fine without updating major version.

[sitiom]

• Related to Handle Multiple Major Versions of One Package #794 (reply in thread)

Meanwhile, I should still be able to download the latest major version by specifying Python.Python.3. So, for example, currently, Python.Python.3 should download Python.Python.3.10. Or maybe even Python.Python downloading Python.Python.3.