Skip to content

chore(release): 9.3.0 [skip-runtime-e2e] - #224

Draft
saurabhjain1592 wants to merge 1 commit into
mainfrom
release/9.3.0-prep
Draft

chore(release): 9.3.0 [skip-runtime-e2e]#224
saurabhjain1592 wants to merge 1 commit into
mainfrom
release/9.3.0-prep

Conversation

@saurabhjain1592

@saurabhjain1592 saurabhjain1592 commented Sep 6, 2026

Copy link
Copy Markdown
Member

Release-prep for the AxonFlow v10.4.0 platform train. Prep record: axonflow-internal-docs engineering/releases/release-notes/v10.4.0-release-record.md; platform tracking issue getaxonflow/axonflow-enterprise#3657.

Mechanical. Version file + the CHANGELOG heading, nothing else. No source change, no behaviour change. Every word of the release notes below was already merged and already reviewed; this PR only stops it being invisible.

Why this PR exists at all

A census of all five SDK repositories on 2026-09-06, run against each repository's default branch through the GitHub API rather than a local clone, found the same thing in each: the version file is byte-identical to the latest published tag, while ## [Unreleased] holds a substantial, already-merged, never-released section. Here the merged-but-unreleased work is the read-path identity change (explain / list scoped to a per-user identity, the vacuous empty read refused, sdk-go#213) together with the telemetry pass: RegisterAdapter, a heartbeat that fires on first outbound use rather than at construction, a 64-byte bound on every relayed value, an in-memory cadence for runtimes where the stamp file cannot be written, and a failure backoff that stops an air-gapped deployment probing its own platform hourly.

That is the v10.3.0 failure repeating. On that train all five SDKs merged the AuthZEN surface and none was version-bumped, because the prep brief had scoped the session to the platform repository. RUNBOOK_RELEASE_PREP.md Step 3 says in terms that "all repos" is load-bearing and that a brief handing a narrower scope is wrong, so this train's prep opens the bump here rather than reporting it.

The CHANGELOG rename is load-bearing, not cosmetic

.github/workflows/release.yml refuses to publish a tag whose version has no CHANGELOG section:

awk -v ver="$VERSION" '$0 ~ "^## \\["ver"\\]" {p=1; next} p && /^## \[/ {exit} p {print}' CHANGELOG.md
...
::error::No CHANGELOG.md section found for version $VERSION — refusing to publish.

So renaming [Unreleased] to [9.3.0] in place is what makes the tag publishable, and it is also what puts the already-merged work into the GitHub release body — the workflow uses that same extraction as the release notes. Renaming in place, rather than inserting a new heading above [Unreleased], is deliberate: an inserted heading strands everything below it, so the release would publish the code and describe none of it.

What ships under this version

The [9.3.0] section is the previous [Unreleased] section verbatim — git diff is two changed lines in the CHANGELOG (the heading) plus the one-line const Version bump. Nothing was added to it, removed from it, or reworded, so this PR makes no claim of its own about the release's contents.

Ordering

Do not tag this before the community platform release. The platform is the anchor: publishing a client artifact for a platform that then rolls back ships an artifact for a platform that does not exist. RUNBOOK_PLATFORM_RELEASE.md §Sequence — platform tag and build, then community sync and release, then the SDKs, then the plugins, then the integration packages.

The platform advertises 9.3.0 on /health from the v10.4.0 release commit (platform/shared/sdkcompat), so this tag completes a claim the platform is already making. If this release is dropped, that advertised version has to come back out of sdkcompat before the platform is tagged — a /health recommending a version nobody can install is the v9.7.0 phantom-version incident.

Checks

go build ./... clean and go test ./... green on the committed head — expected, since no source file is touched. version.go's const Version is the on-wire sdk-go/<Version> value, so a tag without this bump silently desyncs the header from the registry version; that is why the const and the tag move together.

Opened as a draft and left for the operator's merge pass, per the merge gate: the worker never self-merges, and every customer-facing repository is the operator's.

Skip-runtime-e2e justification

This PR changes version.go and CHANGELOG.md only. version.go is a root-level file, so the Definition of Done gate classifies the diff as user-facing surface — correctly, because that constant IS the on-wire client identity. But the change is a version string for release prep: no new behaviour, no new method, no new field, nothing a runtime proof could exercise that is not already exercised. The read-path identity surface shipping under 9.3.0 has its own runtime proof in runtime-e2e/read_path_identity/, landed with the code in #213.

Every capability shipping under 9.3.0 already carries its own runtime proof, landed with the code in the PR that added it — this PR adds none of that code, it renames the section the code is already described in. A runtime-e2e test written for a version bump would assert that the SDK reports the number this PR just typed, which is a tautology against version.go, not a proof.

This is the established handling for this exact class in this repository, not a new exemption: chore(release): prep v9.2.0 [skip-runtime-e2e] (#206), chore(release): v9.1.1 [skip-runtime-e2e] (#200) and chore(release): v9.1.0 [skip-runtime-e2e] (#198) are the three most recent release-prep PRs here and all three used it, with the same reasoning. Flagged to the release master rather than assumed: if the operator would rather have a runtime leg than an exemption, say so and it becomes one.

The runtime leg this gate would ask for ALREADY EXISTS, and it is executed

Added after review, because it is the strongest thing either side of this exemption can say and it was missing from the justification above.

If a reviewer asked "what would a runtime proof of a version bump even assert?", the honest answer is: that the version the artifact PUBLISHES under and the version it REPORTS on the wire are the same number. This repository already asserts exactly that, against a live agent, in an executed suite:

runtime-e2e/x-axonflow-client/main.go:84expected := "sdk-go/" + axonflow.Version, then asserts the live agent echoes that exact string back in its scope_mismatch response.

This SDK has exactly ONE version site, version.go's const Version, so "the wire carries the version file" is the whole property, and that line is it.

So the exemption is not "there is nothing worth proving here". It is "the thing worth proving is already proven by a suite that runs, and this PR does not change the code it proves anything about". A second assertion of the same property, added to satisfy a gate, would be the duplication the guard is not asking for.

@saurabhjain1592 saurabhjain1592 changed the title release: 9.3.0 chore(release): 9.3.0 [skip-runtime-e2e] Sep 6, 2026
Version file and the CHANGELOG heading. No source change.

`[Unreleased]` is renamed in place to `[9.3.0]` rather than having a new
heading inserted above it: the release workflow's preflight extracts the
release body with `awk` from `^## [<version>]` to the next `## [`, so an
inserted heading would publish the code and describe none of it, stranding
the read-path identity work and the whole telemetry pass under an
`[Unreleased]` heading sitting below a released one.

`const Version` is the on-wire `sdk-go/<Version>` value, so it moves with the
tag or the header desyncs from the registry.

Release-prep Step 3 for the v10.4.0 platform train.

Signed-off-by: Saurabh Jain <saurabh.jain@getaxonflow.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant