Pipelines should warn against incorrect inclusion / exclusion of DisplayVersion about winget-pkgs HOT 4 OPEN

For this the implementation details can be:

Query all manifests of a given PackageIdentifier:

• If the immediate previous manifest contains DisplayVersion:

  • Verify that the new manifest also contains DisplayVersion
  • Verify that DisplayVersion != PackageVersion field in the manifest

• If the immediate previous manifest does not include DisplayVersion:

  • Verify the newer manifest does NOT include it

• Throw a warning if inconsistencies are found i.e., some manifests include DisplayVersion and some don't

Oh yes,, these checks should also be performed. Maybe during manifest validation, which happens earlier in the process, before the package install into a VM.

Currently, a reduced form of this check (only checking against 1 previous manifest) is performed during validation. Shifting this check forward in the process would be beneficial. For best user experience, all errors should be presented at once and early in the process, allowing them all to be fixed in one remediation cycle.

• Right now, users can encounter a manifest error, an installer error, and a validation error, and have to come back and fix their PR 3 times or more. Moving this check forward in the pipeline process will help reduce that number closer to 1.

This check (sanity check DisplayVersion against previous manifest versions) couples nicely to the other check (verify installed DisplayVersion matches manifest DisplayVersion) to help ensure matching.

from winget-pkgs.

This is essential for matching, which drives upgrades.

Implementation thoughts:

Since the validation pipeline performs a package install, this data should be available in validation VM just afterwards, then become emitted in the logs as a pipeline message or warning - maybe DisplayVersion Mismatch - the DisplayVersion from the manifest does not match data in Windows Registry or similar. And have a PR label attached. From there, various PR automation could transport the error into the PR comments.

Ideally, this message wouldn't block the rest of the validation pipeline process - similar to the "needs manual review" type of output, this would emit into logs, and our existing PR automation would add the appropriate label.

from winget-pkgs.

Since the validation pipeline performs a package install, this data should be available in validation VM just afterwards, then become emitted in the logs as a pipeline message or warning - maybe DisplayVersion Mismatch - the DisplayVersion from the manifest does not match data in Windows Registry or similar. And have a PR label attached. From there, various PR automation could transport the error into the PR comments.

I think the implementation detail above is relevant to issues like:

• #13620
• #118948

This issue focuses more on checking the state of previous manifests in a given PackageIdentifier and determining whether including / excluding AppsAndFeaturesEntries: DisplayVersion would cause version range issues or not. Even if the DisplayVersion correctly matches whatever is written to ARP, including it in the manifest may not always be a good idea. There are many cases where having a valid PackageVersion field that matches ARP suffices; using DisplayVersion in these cases causes unnecessary version mapping, and leads to the "infinite upgrade" scenario.

from winget-pkgs.

For this the implementation details can be:

Query all manifests of a given PackageIdentifier:

• If the immediate previous manifest contains DisplayVersion:

  • Verify that the new manifest also contains DisplayVersion
  • Verify that DisplayVersion != PackageVersion field in the manifest

• If the immediate previous manifest does not include DisplayVersion:

  • Verify the newer manifest does NOT include it

• Throw a warning if inconsistencies are found i.e., some manifests include DisplayVersion and some don't

from winget-pkgs.