ReplacedBy key for manifests

[Trenly]

Description of the new feature/enhancement

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. Additionally, some older software that is no longer maintained may be picked up by a different user and published under a different package name. If there were a manifest key to indicate that a different package may be available than the package they elected to install, it would be possible to inform users of potential upgrades.

Proposed technical implementation details (optional)

Add a manifest key for `ReplacedBy: <Package.Identifier>

When running an install or an upgrade to the package, if the manifest contains the ReplacedBy key, display an informational message to the user that a newer version of this software may be available under a different name and display the Package Identifier. Continue to install the package they requested to install

When running winget list or upgrade with no arguments, display an informational table following the existing output showing which packages may have newer versions available under a different name.

For Consideration

Would we want to treat such a key as a redirect to the other package for upgrades? If this is something that would be wanted, then winget upgrade should clearly show that new versions will install a different package. Example -

Name	Id	Version	Available	Source
Corsair iCUE Software	Corsair.iCUE.3	3.38.61	[Corsair.iCUE.4] 4.15.153	Winget
Snipping Tool	Microsoft.SnippingTool	1.0.0.1	[Microsoft.SnipAndSketch] 10.2008.2277.0	Winget

In such cases, it would probably be best to notify the user and have them decide they want to manually run winget install <Package.Identifier> to upgrade to the new package

[denelon]

@Trenly I just added #1889 does this cover the scenario here well enough?

[Trenly]

@Trenly I just added #1889 does this cover the scenario here well enough?

Maybe, if the #1899 spec is built right ; I’ll use the example of Corsair iCUE since I’m familiar with it and its what I used in the post.

Corsair still maintains and provides updates to the 3.xx application to support older devices that are still on the market. This package has the identifier 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

The idea here is that a user may be on the 3.xx software and not realize that the newer 4.xx software is available (and may be better suited to their needs).

---

Similarly, there may exist a case where a publisher is no longer actively developing on their open source project but leaves the releases available.

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

[denelon]

These two issues are cross linked. If you don't mind, close this one and be sure to add your concerns to that one so we can make sure to capture the scenario. I guess the problem or challenge is how one would be able to determine that the newer version would work for them, and what a conditional redirect might look like.

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.