Doc for ARP version mapping change #2162
Conversation
| Version `0.0.1-alpha` is less than version `0.0.1-beta` | ||
| Version `0.0.1-alpha` is less than version `0.0.1` | ||
| Version `13.9.8` is less than version `14.0` | ||
| Version `1.0` is equal to version `1.0.0` |
There was a problem hiding this comment.
I don't know the answer, but based on "else if one side has no more parts, it is less ", 1.0 would be less than 1.0.0.
There was a problem hiding this comment.
I agree here, I think that the no-more-parts check should consider 0 the same as an undefined part in terms of equality
There was a problem hiding this comment.
These examples are actually adapted from our unit tests, so these are what we are currently using for version comparison now. During parsing, version parts with 0 only get dropped. That's why 1.0.0 == 1.0. I'll update the doc to clarify that.
|
|
||
| ### How Winget collects and stores ARP version | ||
|
|
||
| The `DisplayVersion` field under `AppsAndFeaturesEntries` will be treated as ARP versions of the package. |
There was a problem hiding this comment.
What will happen if a single app has multiple AppsAndFeaturesEntries for all of its components (e.g - Firefox) ? Is it expected that the first entry in AppsAndFeaturesEntries should be the "primary" component ARP entry?
There was a problem hiding this comment.
I'm beginning to wonder if we need to have a primary boolean for this, as when I was trying to fix the table this came up too. I don't think we should assume the array is sorted properly, as the current tooling to get AppsAndFeaturesEntries just uses whatever order the table is in (so alphabetical, meaning things like "Microsoft VC Redist 2013-2015 x64" could come before "Mozilla Firefox 100.0").
There was a problem hiding this comment.
I'm beginning to wonder if we need to have a
primaryboolean for this
We do, although I would expect that if there are multiple components listed, only the primary one needs to have the DisplayVersion set. Certainly a potential pitfall though. Having flags like primary (and others) would also enable the complex scenarios that your PR attempted to address (with the proper internal tracking of course).
| Version `> 3.0` is less than version `3.1` (because `3.0` is less than `3.1`) | ||
| Version `> 3.0` is greater than version `2.9` | ||
|
|
||
| **Note:** It is recommended for package authors to update ARP version info for all package versions of a package for better version mapping if this feature is to be used for a package. |
There was a problem hiding this comment.
What if a publisher updates the ARP version but not the Marketing version? How should that be handled? I'm specifically thinking more from a manifest-creation and winget-pkgs standpoint here
There was a problem hiding this comment.
There can only be one package (Marketing) version manifest, so it would be an update to that, replacing it. This would be the case for a bug fix only update that is intended to fully replace the existing version.
For #980
Microsoft Reviewers: Open in CodeFlow