Release 0.9.5 (#54)

Bumps `VersionPrefix` so the Store stage can be exercised with the
upload timeout fix
from #52.

A pipeline run uses the YAML on `main` as of that run, so #52 could not
be applied to
0.9.4 after the fact, and the Release stage refuses to reuse an existing
tag — which is
what the failed run after #52 merged was showing.

## No product change

Everything on `main` since `v0.9.4` is pipeline and documentation. The
binaries are
identical to 0.9.4; this release exists to put a version through the
Store stage.

## What the run should show

Two paths get their first real test, in this order:

1. **Clearing the abandoned submission.** The failed 0.9.4 attempt left
one in
`PendingCommit`. The stage deletes exactly that state and continues; any
other status
   still fails untouched.
2. **The upload.** With `--uploadTimeout` set, the blob client no longer
gets a zero
network timeout. Publish runs verbose, so a failure reports its own
exception instead
   of one swallowed line.

If it fails anyway, the GitHub release is already published by then and
every download is
unaffected — the stage runs after Release for exactly that reason.

## Verified locally

`dotnet build Whiteboard.sln -c Release` clean, no warnings; Core smoke
tests pass.

Author: marcosqlbi

Directory.Build.props

@@ -5,7 +5,7 @@
       scripts/build-installer.ps1 both read it from here, so releasing is a reviewed change
       to this line rather than an edit in a pipeline variable group.
     -->
-    <VersionPrefix>0.9.4</VersionPrefix>
+    <VersionPrefix>0.9.5</VersionPrefix>
     <LangVersion>latest</LangVersion>
     <Nullable>enable</Nullable>
     <ImplicitUsings>enable</ImplicitUsings>

TODO.md

@@ -16,7 +16,7 @@ The delivery chain works end to end: a merge to `main` builds, signs, and publis
 pre-release to GitHub Releases, and one approval promotes that same build to a release.
 <https://whiteboard.sqlbi.com> reads its download links from the release manifest
 deployed beside it and needs no edit per release. The current product version is `VersionPrefix` in `Directory.Build.props`
-(0.9.4). Identity version for the Store package is `VersionPrefix.0` (`0.9.4.0`).
+(0.9.5). Identity version for the Store package is `VersionPrefix.0` (`0.9.5.0`).
 
 What 1.0 was waiting on is in the product: Preferences, `.wimport`, Explorer and VS Code
 previews, the public documentation site, and Finger drawing (default when no pen is
@@ -58,13 +58,16 @@ visible and gates nothing.
 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, but the fix has not been exercised — a pipeline run uses the YAML on `main` at the
-time it runs, and 0.9.4 cannot be released twice, so the next promoted release is the one
-that proves it.
+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.
 
-0.9.4 was not submitted to the Store. Nothing depends on the Store carrying every version,
-and the alternative was submitting it by hand, which is the thing this stage exists to
-avoid.
+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.

docs/decisions.md

@@ -302,7 +302,7 @@ ships can inherit it by accident.
 ## Open questions
 
 - Whether 1.0.0 is declared, and on what. `VersionPrefix` in `Directory.Build.props`
-  reads `0.9.4`, the released channel has been published since `0.9.0`, and `0.9.2` is
+  reads `0.9.5`, the released channel has been published since `0.9.0`, and `0.9.2` is
   the version live in the Store. Nothing is blocked on the number; what is open is
   what has to be true before it stops being 0.x.
 - arm64 is not built; add it if Surface devices matter for a pen application.