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)