Release 0.9.4 (#51)

Bumps `VersionPrefix` to 0.9.4 so the Store stage added in #50 has a
version to submit.

Two constraints make a bump the only way to exercise it. The Release
stage refuses to
reuse an existing tag, by design, so 0.9.3 could not be released a
second time to carry
the test. And the Store rejects an identity version it has already
published.

0.9.2 finished publishing and is live in the Store, which clears the
precondition the
stage depends on: `msstore publish` clones the last published
submission, and until now
there was not one.

## What happens when this merges

The Azure pipeline builds and signs, and publishes `0.9.4-dev.N` to the
pre-release
channel. Approving the Release stage then publishes the `v0.9.4` release
and runs the
**Store** stage for the first time, which submits that run's MSIX.

What to watch on that run is in TODO.md: the MSIX must come out of
`drop-x64-true`, and
a submission pending in Partner Center would make the stage fail by
design. Neither
affects the download — the GitHub release is already published by the
time the Store
stage starts.

## 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.3</VersionPrefix>
+    <VersionPrefix>0.9.4</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.3). Identity version for the Store package is `VersionPrefix.0` (`0.9.3.0`).
+(0.9.4). Identity version for the Store package is `VersionPrefix.0` (`0.9.4.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
@@ -60,9 +60,9 @@ manual one for 0.9.2, and the stage was written against the documented behaviour
 Microsoft Store Developer CLI rather than against a run of it. The first promoted release
 after this lands is the one that proves it.
 
-It needs a version the Store has not seen. The Release stage refuses to reuse an existing
-tag, so exercising this at all means bumping `VersionPrefix` — 0.9.3 cannot be released a
-second time to carry the test.
+0.9.4 is that release. `VersionPrefix` was bumped for it, because the Release stage
+refuses to reuse an existing tag and 0.9.3 could not be released a second time to carry
+the test.
 
 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

@@ -301,8 +301,8 @@ 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.3`, the released channel has been published since `0.9.0`, and `0.9.2` is
-  the version submitted to the Store. Nothing is blocked on the number; what is open is
+  reads `0.9.4`, 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.
 - The brand mark is placeholder-grade (decision 12).