Ability to update DisplayVersion in autonomous update

[mdanish-kh]

Description of the new feature / enhancement

Many packages in the winget repository use a different marketing version than the DisplayVersion they write to the Registry. As such, their manifests include both the PackageVersion & DisplayVersion field. Many publishers follow a consistent pattern with their PackageVersion & DisplayVersion values. As such DisplayVersion can be known for such publishers without manually installing the package.

The current flow for such packages is to create a PR first using wingetcreate, then manually update the DisplayVersion field in the PR. wingetcreate should offer a way to update the DisplayVersion as part of the autonomous update.

Proposed technical implementation details

A simple --display-version arg wouldn't suffice as DisplayVersion can be different per installer node. There should be a way to provide it for each installer URL with overrides as we have right now for architecture & scope. I'm thinking of the following UX, would love additional thoughts or concerns:

• wingetcreate update x.x --version 1.2.3 --display-version 4.5.6 --urls <InstallerUrls>... -> Looks for all installer nodes that have a DisplayVersion value and replaces it with 4.5.6. Do nothing for those that do not have a previous DisplayVersion value.

• wingetcreate update x.x --version 1.2.3 --urls "<InstallerUrl1>|1.2" "<InstallerUrl2>|x64|2.3" "<InstallerUrl3>|machine|3.4" "<InstallerUrl4>|x86|user|4.5" -> Replaces the DisplayVersion of installer nodes that match the arch,scope etc with the provided values. If the existing nodes do not have a DisplayVersion value then do nothing.

• wingetcreate update x.x --version 1.2.3 --display-version 4.5.6 --urls "<InstallerUrl1>|1.2" "<InstallerUrl2> " "<InstallerUrl3>" "<InstallerUrl4>" -> Matching installer node for InstallerUrl1 gets DisplayVersion 1.2, rest will get the value provided with --display-version arg. For those existing nodes do not have a DisplayVersion value, do nothing.

[Trenly]

I wonder if there isn't a need for an object type input something like:

[
  {
    "URL:": "https://example.com/1.exe",
    "Scope": "user",
    "Architecture": "x64",
    "DisplayVersion": "1.2.3_64"
  },
  {
    "URL:": "https://example.com/2.exe",
    "Scope": "user",
    "Architecture": "x86",
    "DisplayVersion": "1.2.3_86"
  },
  {
    "URL:": "https://example.com/3.msi",
    "Scope": "machine",
    "DisplayVersion": "1.2.3"
  },
]

Treat it the same way you would an override for a URL, but then it's a bit more "user-friendly" for autonomous updates, since the workflow could build up a single object to pass in

[mdanish-kh]

I wonder if there isn't a need for an object type input

I didn't handle this in the current PR resolving this issue, but this sounds like a great UX improvement. I'll create a separate issue for tracking this request.