Review and promote a native runtime release
This maintainer runbook connects reviewed development source to authenticated
developer bundles, a native runtime release and versioned documentation. The
September 28, 2026 maintainer instruction authorizes 0.1.0-alpha.5 promotion,
publication and Pages deployment after the required checks. It does not waive
CI, artifact authentication, VM acceptance or configured environment reviews.
Use the native release gate for the complete acceptance contract and retained alpha.4 history. That evidence keeps its original source and archive identities; a new version requires fresh runs. No Azure resources or simulated cloud qualification are part of this release.
1. Prepare and review development
Complete release changes through dedicated PRs into development, with
successful CI and squash/admin merges. Synchronize workspace and SDK versions,
lockfiles, the reviewed security inventory and current setup guides. C and Go
source SDKs use the repository release tag. Preserve historical documentation
snapshots, receipts and published tags.
Build new developer tools and a disposable native test node from the same exact
versioned source using Developer tools and Native runtime candidate.
Select development_test_node: true for the latter. Independently select the
repository, workflow, source ref, commit, version and candidate purpose before
consuming their attestations.
Run Packaged developer qualification against those exact successful run IDs
and policies for Linux, Windows and WSL2. Select only the newly authenticated
artifacts in packaging/dev/release-selection.json, recording their real sizes
and hashes. Merge that selection through a reviewed PR. Never rename alpha.4
bundles to imply an alpha.5 build or copy their hashes into the new selection.
2. Authenticate the actual predecessor
Alpha.5 selects the published alpha.4 runtime as its predecessor:
| Identity | Selection |
|---|---|
| Version | 0.1.0-alpha.4 |
| Source | 2d6cc2eafc0a17dfe573be4252fa49835bebbbd6 |
| Release run | 36278662081 |
| Archive SHA-256 | a823a3c5b06ee81a09e39053451e768ee7b22199e37c3b524f89843db7b045b3 |
Inspect the immutable tag and completed run. Download its native artifact to a
new private directory, then follow the
independent bootstrap verification sequence.
Require the release workflow's tag/source/signer identities and check every
listed digest before running downloaded code. The predecessor entry in
packaging/linux/compatibility.json must match the authenticated manifest.
Installer/configuration formats remain 1 with no migration selected. This declaration alone is not proof of compatibility: the final native VM campaign must install alpha.4, preserve its state while upgrading, and reject an unsupported downgrade. The older rc.2 pair remains historical alpha.4 evidence.
3. Promote the complete source
Open the development-to-release promotion PR. Confirm its final tree contains
all reviewed runtime, SDK, helper, dependency and documentation changes. After
successful CI, squash merge with --admin, then require successful CI at the
actual resulting release commit. A pre-merge PR commit is a different identity.
Inspect the registered native release workflow and its protected
native-runtime-publish environment. Its deployment allowlist must include the
exact approved tag, while retaining the required reviewer and existing protection
rules. Do not substitute a wildcard or disable the review. Create the immutable 0.1.0-alpha.5 tag
once at that exact release commit. Do not move an existing tag to a rebuild.
4. Qualify and publish the runtime
Dispatch .github/workflows/native-runtime-release.yml at the tag, supplying:
| Input | Value |
|---|---|
version | 0.1.0-alpha.5 |
commit | The exact tagged release commit |
ci_run | Successful CI for that exact commit |
predecessor_run | 36278662081 |
publish | true, under the maintainer's publication authorization |
The workflow builds and attests the actual archive, authenticates the committed
developer selection, and boots real Ubuntu VMs for local-experimental-v1 and
external-capsule-v1. Both must pass installation, retained state, reboot, the
declared upgrade and unsupported downgrade rejection. Require
acceptanceComplete: true, empty gaps and the exact artifact/source identities.
An ordinary candidate run or same-version reinstall cannot satisfy this gate.
Review the protected publication job only after those checks succeed. Do not disable protection or manufacture successful receipts. If publication reports an uncertain result, inspect the remote release and the gate's retained journal before any retry; published assets must not be silently overwritten.
Upload the exact qualified developer assets named by the authenticated selection and their verification material. Describe additions, installation paths, the upgrade pair and remaining limitations in the release notes. Independently verify public asset inventory, sizes, hashes and publisher identities.
5. Publish the matching website
Create a new documentation snapshot bound to the actual runtime release commit,
reviewed documentation commit and example source. Keep previous snapshots
immutable and follow versioned documentation.
Merge the snapshot through development and require its successful push CI and
website artifact.
Use the single .github/workflows/docs-pages.yml publisher on release, with
that exact development source, CI run and attempt. Complete its configured
environment review and live browser checks. A source merge does not deploy Pages.
Verify live source identity, the alpha.5 selector, setup downloads, language tabs
and new web/container guide navigation before reporting completion.