From c535aa936a68c40008debbca025a9eabddbdd2de Mon Sep 17 00:00:00 2001 From: Marco Russo Date: Sun, 23 Aug 2026 16:10:58 +0200 Subject: [PATCH] Bring the standing documents up to 1.0.0 TODO.md still described the first automated Store submission as something to watch. It happened: the pipeline carried 0.9.5 through certification unattended, which STORE-LISTING.md already recorded and TODO.md did not. That section is gone, and what it explained about the upload timeout and the abandoned submission was already the durable record in release-management.md rather than anything only TODO.md held. winget is now the one piece still outstanding, and its pull request is still open. In its place is the thing that genuinely is outstanding at 1.0.0: nothing in the install-side verification list has ever been done for a real release. That mattered less through 0.9.x, when the number invited nobody to install fresh. README.md described the hover indicator as a dot, which stopped being the whole story when the laser and the eraser started drawing their own, and its Preferences list predates the trail weight setting. Co-Authored-By: Claude Fable 5 --- README.md | 4 ++-- TODO.md | 49 ++++++++++++++++++++----------------------------- 2 files changed, 22 insertions(+), 31 deletions(-) diff --git a/README.md b/README.md index 215df43..80f3b1d 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ How the project is developed and shipped is documented separately: ## Included in the application - Low-latency, pressure-aware WPF wet ink, including rear-eraser detection on any pen that reports it -- A normal cursor for physical mouse input and a high-contrast pen-hover dot that disappears on contact +- A normal cursor for physical mouse input, and a pen-hover indicator that shows what a tap would do: the laser with its halo and speed trail, a dashed square around what the eraser would clear, and a high-contrast dot for everything else. All of them disappear on contact - Touch panning and two-finger pinch zoom - Optional finger drawing (default when no pen is detected): one finger uses the current tool, two fingers still pan and pinch-zoom, and Eraser and Pan appear on the toolbar - Basic palm rejection: touch navigation is suspended when the pen makes contact @@ -28,7 +28,7 @@ How the project is developed and shipped is documented separately: - Markdown `.wimport` recipes that build image and text containers from headings - An intentionally small floating toolbar - A File / Edit / View / Help tab strip. Click a tab for a one-row command strip over the canvas -- Preferences for the startup monitor, full-screen start, finger drawing, snippet format order, laser trail, toolbar position and layout, and (except Store installs) a daily new-version check +- Preferences for the startup monitor, full-screen start, finger drawing, snippet format order, laser trail timing and weight, toolbar position and layout, and (except Store installs) a daily new-version check - About, with version and channel ## Build and run diff --git a/TODO.md b/TODO.md index 21fdae7..bff08d1 100644 --- a/TODO.md +++ b/TODO.md @@ -18,18 +18,20 @@ pre-release to GitHub Releases, and one approval promotes that same build to a r deployed beside it and needs no edit per release. The current product version is `VersionPrefix` in `Directory.Build.props` (1.0.0). Identity version for the Store package is `VersionPrefix.0` (`1.0.0.0`). -What 1.0 was waiting on shipped during 0.9.x: Preferences, `.wimport`, Explorer and VS -Code previews, the public documentation site, and Finger drawing (default when no pen is -detected). The Store listing was submitted by hand on 20 August 2026 for 0.9.2. +Declaring that number is decision 20 in [docs/decisions.md](docs/decisions.md). What 1.0 +was waiting on shipped during 0.9.x: Preferences, `.wimport`, Explorer and VS Code +previews, the public documentation site, and Finger drawing (default when no pen is +detected). No numbered work remains. The video teaser is recorded and served from the landing page itself as `site/teaser-av1.mp4` / `site/teaser-h264.mp4` — the Vimeo-embed plan was reversed, see decision 19 in [docs/decisions.md](docs/decisions.md); the production -script and staging assets are in `docs/teaser/`. The release manifests, winget, and -Store submission are done: the manifests are live at -, the first winget submission is in review, -and the pipeline's Store stage submits each promoted release. All three are described -in [docs/release-management.md](docs/release-management.md). +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 +[docs/release-management.md](docs/release-management.md). ## Waiting on the first winget submission @@ -43,26 +45,15 @@ Until that pull request merges, `.github/workflows/publish-winget.yml` fails on release, because `wingetcreate update` has no previous version to read. That failure is visible and gates nothing. -## Waiting on the first automated Store submission +## Before promoting 1.0.0 -Also not work. The stage ran for the first time on 0.9.4 and failed: it authenticated, -created the submission, and then could not upload the package, because `msstore publish` -defaults its blob upload timeout to zero when `--uploadTimeout` is not given. That is -fixed, and 0.9.5 is the release that exercises the fix — a pipeline run uses the YAML on -`main` at the time it runs, so the fix could not be applied to 0.9.4 retroactively. +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". -0.9.4 was never submitted to the Store, and 0.9.5 carries no product change over it: the -binaries are identical, and the release exists to put a version through the Store stage. -Nothing depends on the Store carrying every version, and the alternative was submitting by -hand, which is the thing this stage exists to avoid. - -That run also clears the abandoned submission 0.9.4 left behind, which is the first test of -that path as well. - -Watch two things on that run. The stage has to pick the MSIX out of `drop-x64-true`, since -both matrix jobs pack an identically named package and only one of them is self-contained. -And a submission already pending in Partner Center makes `msstore publish` fail by design — -the stage does not delete someone else's in-flight submission to make room for its own. - -Nothing gates on it. The stage runs after the GitHub release exists, so a failure leaves -every download in place and is visible as a failed stage. +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.