new-version: update an MSI installer's ProductCode, and refuse to copy a stale one #18

New issue

Closed

opened 2026-10-14 03:10:08 -05:00 by jeff · 0 comments

jeff commented

2026-10-14 03:10:08 -05:00

Owner

Part of #5
Blocks: #5 (harrier's half)

wingetsource new-version copies an installer's ProductCode unchanged from the
version it copies. An MSI built with Product Id="*" has a new ProductCode
every release, so a copied one is wrong, and check does not notice.

This is live: harrier's release.yaml already has a winget job (jeff/harrier
9728f73), and now that JCOllie.Harrier 0.1.0 exists (#16), harrier's next
release would open a submission carrying 0.1.0's ProductCode
{3BC82F39-D1BE-45F4-8BA4-9CFBCF01F211} — one that passes its check.

What harrier's manifest changes per release

From manifests/j/JCOllie/Harrier/0.1.0/JCOllie.Harrier.installer.yaml:
ProductCode sits under the x64 installer; the top-level
AppsAndFeaturesEntries holds only the stable UpgradeCode and no
DisplayVersion. So Installers[x64].ProductCode is the only per-release
field new-version does not already rewrite.

The change

Refuse rather than copy. If an installer being copied has a
ProductCode and no new one is given for its architecture, new-version
fails, writing nothing, with a message saying --product-code is needed.
Same for a DisplayVersion anywhere in the installer file, since there is
no option to supply one (no package has one today). This is the urgent part:
it turns harrier's next release from a wrong submission into a failed job.
--product-code ARCHITECTURE=CODE, repeatable like --installer,
replacing that installer's ProductCode. Fails if given for an architecture
whose installer has none, or for one with no --installer. The code is
written quoted, as in the existing manifest ('{...}'), and checked to be a
braced GUID.
--json output unchanged.

Both are additions to new-version's behaviour and options, so the command
line stays compatible (ADR 0004). Item 1 does change what an existing
invocation does, but only for a package whose installers carry a
ProductCode — today only harrier, for which the current behaviour is wrong.

Also

Tests: refusal with and without a ProductCode; replacement per
architecture; the option given for an architecture without one; a bad GUID;
copying JCOllie.Harrier 0.1.0 with and without the option.
CONTRIBUTING's new-version paragraph lists the option and the refusal.

Then

jeff/winget-submit gains a product-codes input passed through as
--product-code (filed there), and harrier's winget job reads the code from
the built MSI with msiinfo and passes it.

Part of #5 Blocks: #5 (harrier's half) `wingetsource new-version` copies an installer's `ProductCode` unchanged from the version it copies. An MSI built with `Product Id="*"` has a new `ProductCode` every release, so a copied one is wrong, and `check` does not notice. This is live: harrier's `release.yaml` already has a `winget` job (jeff/harrier 9728f73), and now that `JCOllie.Harrier` 0.1.0 exists (#16), harrier's next release would open a submission carrying 0.1.0's `ProductCode` `{3BC82F39-D1BE-45F4-8BA4-9CFBCF01F211}` — one that passes its check. ## What harrier's manifest changes per release From `manifests/j/JCOllie/Harrier/0.1.0/JCOllie.Harrier.installer.yaml`: `ProductCode` sits under the `x64` installer; the top-level `AppsAndFeaturesEntries` holds only the stable `UpgradeCode` and no `DisplayVersion`. So `Installers[x64].ProductCode` is the only per-release field `new-version` does not already rewrite. ## The change 1. **Refuse rather than copy.** If an installer being copied has a `ProductCode` and no new one is given for its architecture, `new-version` fails, writing nothing, with a message saying `--product-code` is needed. Same for a `DisplayVersion` anywhere in the installer file, since there is no option to supply one (no package has one today). This is the urgent part: it turns harrier's next release from a wrong submission into a failed job. 2. **`--product-code ARCHITECTURE=CODE`**, repeatable like `--installer`, replacing that installer's `ProductCode`. Fails if given for an architecture whose installer has none, or for one with no `--installer`. The code is written quoted, as in the existing manifest (`'{...}'`), and checked to be a braced GUID. 3. `--json` output unchanged. Both are additions to `new-version`'s behaviour and options, so the command line stays compatible (ADR 0004). Item 1 does change what an existing invocation does, but only for a package whose installers carry a `ProductCode` — today only harrier, for which the current behaviour is wrong. ## Also - Tests: refusal with and without a `ProductCode`; replacement per architecture; the option given for an architecture without one; a bad GUID; copying `JCOllie.Harrier` 0.1.0 with and without the option. - CONTRIBUTING's `new-version` paragraph lists the option and the refusal. ## Then jeff/winget-submit gains a `product-codes` input passed through as `--product-code` (filed there), and harrier's `winget` job reads the code from the built MSI with `msiinfo` and passes it.

jeff added the

ready-for-agent

label

2026-10-14 03:10:08 -05:00

jeff referenced this issue from jeff/winget-submit

2026-10-14 03:10:18 -05:00

Pass product codes through to new-version #6

jeff added a new dependency

2026-10-14 03:10:18 -05:00

jeff/winget-submit#6 - Pass product codes through to new-version

jeff added a new dependency

2026-10-14 03:10:19 -05:00