Additional AppsAndFeaturesEntry fields for ARP Matching

[Trenly]

Description of the new feature / enhancement

In the AppsAndFeaturesEntry, there are additional fields which could be used for ARP Matching if they were added to the manifest and were populated by package maintainers. Any available ARP fields could be added to the manifest to improve ARP Matching

Proposed technical implementation details

AppsAndFeaturesEntries:
  - DisplayName: # This already exists
    Publisher: # This already exists
    DisplayVersion: # This already exists
    ProductCode: # This already exists
    UpgradeCode: # This already exists
    InstallerType: # This already exists
    HelpLink: # This is new
    UrlInfoAbout: # This is new
    URLUpdateInfo: # This is new
    EstimatedSize: # This is new

[denelon]

@Trenly how are these related to matching? When would you see a user wanting to see these?

[Trenly]

@Trenly how are these related to matching? When would you see a user wanting to see these?

When a user forks an open source application and begins to distribute their own version, especially with nullsoft based applications, there are times that the Display Name, Product Code, etc are left unchanged, but items like the HelpLink automatically change to show which repository compiled the application. This has a low (but non-zero) chance of overlapping with existing package ARP entries unless the additional fields are considered.

It would also be helpful to write some of these fields, such as UrlInfoAbout and HelpLink when installing portable apps.

Finally, some apps published by NVIDIA all have the same ProductCode and version, but differ by their EstimatedSize entry.

(Also, just for the sake of completeness)

[denelon]

Cool. Thanks for the clarification. I'm going to have to move this out, but I wanted to understand the context. We're going to bump the schema version to match the client version for 1.4. I'll be updating issues accordingly.