From 4c501ab5c46ec2b36a9e8e8bbe490017ae153e68 Mon Sep 17 00:00:00 2001 From: Marco Russo Date: Sun, 23 Aug 2026 17:30:41 +0200 Subject: [PATCH] Record 1.0.0 as shipped and verified MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The install-side verification list was walked in full for 1.0.0 — signtool on each MSI, install, upgrade and uninstall per scope, .wboard by double-click, both channels side by side, and SmartScreen on a clean machine. It was the last part of the chain that had only ever been reasoned about, so release-management.md no longer describes it as never done, and the TODO section that asked for it before promotion is gone. The Store listing is on 1.0.0. Certification now runs unattended in under an hour rather than the hours to days it took when decision 13 was written, which changes how long the Store lags the download rather than the reasoning: it is still someone else's queue and still must not gate a release that is already built and signed. Decision 13 says so directly rather than resting on a timing that has since moved. STORE-LISTING.md and the site verification script join installer/winget in the pipeline's exclude list. Neither is read by a build, and the exclusion is there so a change to distribution metadata cannot publish a pre-release byte-identical to the one before it. Only the one markdown file, since the rest of installer/msix is the package manifest and its assets. Co-Authored-By: Claude Fable 5 --- .azure/pipelines/build-whiteboard.yaml | 5 +++++ TODO.md | 20 ++++---------------- docs/decisions.md | 11 +++++++---- docs/release-management.md | 12 +++++++++--- installer/msix/STORE-LISTING.md | 6 ++++-- 5 files changed, 29 insertions(+), 25 deletions(-) diff --git a/.azure/pipelines/build-whiteboard.yaml b/.azure/pipelines/build-whiteboard.yaml index 595bf54..3dd338a 100644 --- a/.azure/pipelines/build-whiteboard.yaml +++ b/.azure/pipelines/build-whiteboard.yaml @@ -68,6 +68,11 @@ trigger: # that is byte-identical to the one before it. - installer/winget - scripts/build-release-manifests.ps1 + # The same reasoning, one file rather than the folder: the rest of installer/msix is + # the package manifest and its assets, which do go into a build. The listing text is + # a record of what was typed into Partner Center by hand and is read by nothing. + - installer/msix/STORE-LISTING.md + - scripts/verify-published-site.ps1 # Pull requests are validated by .github/workflows/pull-request.yml, unsigned. Without this, # Azure DevOps validates every pull request against a GitHub repository by default, which diff --git a/TODO.md b/TODO.md index bff08d1..981c639 100644 --- a/TODO.md +++ b/TODO.md @@ -28,9 +28,10 @@ itself as `site/teaser-av1.mp4` / `site/teaser-h264.mp4` — the Vimeo-embed pla reversed, see decision 19 in [docs/decisions.md](docs/decisions.md); the production script and staging assets are in `docs/teaser/`. The release manifests and the Store submission are done and proven: the manifests are live at -, and the pipeline's Store stage carried 0.9.5 -through certification unattended, which was the last part of the chain never exercised -end to end. winget is the one piece still waiting, below. All of it is described in +, and the pipeline's Store stage has carried +two releases through certification unattended. The install-side verification list was +walked in full for 1.0.0, which was the last part of the chain that had only ever been +reasoned about. winget is the one piece still waiting, below. All of it is described in [docs/release-management.md](docs/release-management.md). ## Waiting on the first winget submission @@ -44,16 +45,3 @@ token it needs is set. Until that pull request merges, `.github/workflows/publish-winget.yml` fails on every release, because `wingetcreate update` has no previous version to read. That failure is visible and gates nothing. - -## Before promoting 1.0.0 - -The build, signing, and publishing chain is proven. What has never been done for a real -release is everything that involves installing the result — `signtool verify` on each -MSI, install, upgrade and uninstall for each scope, opening a `.wboard` by double-click, -released and pre-release side by side, and a clean machine for SmartScreen. The list is -in [docs/release-management.md](docs/release-management.md) under "Verification before a -public release". - -It mattered less through 0.9.x, when a version number invited nobody to install fresh. -1.0.0 does, so the list is worth walking before the Release stage is approved rather -than after. diff --git a/docs/decisions.md b/docs/decisions.md index caad828..8083841 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -203,10 +203,13 @@ Three constraints shape it: followed (full-trust desktop package, file-type associations in the manifest). - Store version numbers must end in `.0`. The MSIX Identity Version is `VersionPrefix.0`, not the four-part assembly stamp the MSI uses. -- Certification takes hours to days, so submission must never gate the web release. The - Store stage runs after Release rather than beside it: the GitHub release already exists - by the time it starts, so a failed or slow submission changes nothing that shipped, and - a build that was never promoted is never submitted. +- Submission must never gate the web release. Certification took hours to days when this + was decided and now runs in under an hour unattended, which changes how long the Store + lags the download rather than the reasoning: it is still someone else's queue, it can + still stall or reject, and none of that should be able to hold up a release that is + already built and signed. The Store stage runs after Release rather than beside it, so + the GitHub release already exists by the time it starts, a failed or slow submission + changes nothing that shipped, and a build that was never promoted is never submitted. The first submission was manual, and was made on 20 August 2026 for 0.9.2: listing, screenshots, and age rating are one-time work no pipeline performs. diff --git a/docs/release-management.md b/docs/release-management.md index 297b3b0..96de933 100644 --- a/docs/release-management.md +++ b/docs/release-management.md @@ -325,7 +325,8 @@ command line ends up in shell history. The **Store** stage of the Azure pipeline submits the released MSIX to Partner Center. It depends on **Release**, so it runs only for a build that was actually promoted, and only after the GitHub release exists — by the time a submission can fail, every download is -already published. Certification takes hours to days and gates nothing (decision 13). +already published. Certification runs unattended in under an hour, and gates nothing +either way (decision 13). `UseMSStoreCLI@0` installs the [Microsoft Store Developer CLI][msstore]; `msstore reconfigure` authenticates with the `SQLBI-StoreSubmission` group, and `msstore publish` @@ -371,8 +372,13 @@ release without touching the Store. ### Verification before a public release -The build, signing, and publishing chain is proven (see above). What has **not** been done -for a real release is everything that involves installing the result. +Walked in full for 1.0.0, which is the first release it was done for. Everything above is +proven by every release that ships; this list is the part that had only ever been reasoned +about, because nothing before it installs the result. + +Worth repeating whenever the installer authoring changes, since that is what these steps +actually exercise — a missing shortcut, a file association an uninstall left behind, or +SmartScreen on a fresh reputation are invisible to every check that runs earlier. - `signtool verify /pa /v` on each MSI. - Install, upgrade, and uninstall for each scope; confirm uninstall removes the install diff --git a/installer/msix/STORE-LISTING.md b/installer/msix/STORE-LISTING.md index d3692de..63260d9 100644 --- a/installer/msix/STORE-LISTING.md +++ b/installer/msix/STORE-LISTING.md @@ -128,8 +128,10 @@ record of them and a change here means a change made by hand in Partner Center. ## The listing is live -0.9.5 completed certification and is published. The Store ID gives the public -addresses: +1.0.0 is published. Certification now runs in under an hour and needs nobody, +so a promoted release reaches the Store the same day rather than the same week — +which is why the pipeline submitting it unattended is the whole of the work. +The Store ID gives the public addresses: - `https://apps.microsoft.com/detail/9NN5N0L2TMTF` - `ms-windows-store://pdp/?ProductId=9NN5N0L2TMTF` (opens the Store app)