Open denelon opened 1 year ago
If this ask is for msix validation (and I assume so since we only do package version validation for msix at the moment), then it would not be applicable unless we make the change to let msix look at manifest AppsAndFeaturesEntries. Currently, AppsAndFeaturesEntries are representing the ARP registry entries written by win32 apps. For msix, these entries are ignored and not used. We even have a validation that on individual installer level, if AppsAndFeaturesEntries exist with msix, a validation error will be returned.
If we do wish to let msix look at AppsAndFeaturesEntries, we need to go through the code and make sure no extra surprise would happen if we enable this new behavior. And for now I cannot think of a reason to enable this, because msix always have a well defined version (no version mapping is actually needed). And we should implement the MarketingVersion (trenly's proposal) if we want to allow showing a different version other than the appxmanifest version.
The more critical thing to match is the AppsAndFeaturesEntries.DisplayVersion if it's present, then we could allow the match to comply with our policy rather than requiring that the PackageVersion matching.
If the DisplayVersion is not present, then the PackageVersion must match. If the DisplayVersion is present, then it must match, and the PackageVersion is not required to match.
Originally posted by @denelon in https://github.com/microsoft/winget-pkgs/issues/111849#issuecomment-1631335312