chore(release): 9.3.0 [skip-runtime-e2e] - #224
Draft
saurabhjain1592 wants to merge 1 commit into
Draft
Conversation
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>
saurabhjain1592
force-pushed
the
release/9.3.0-prep
branch
from
September 6, 2026 04:49
122d466 to
806813f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release-prep for the AxonFlow v10.4.0 platform train. Prep record:
axonflow-internal-docsengineering/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/listscoped 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.mdStep 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.ymlrefuses to publish a tag whose version has no CHANGELOG section: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 diffis two changed lines in the CHANGELOG (the heading) plus the one-lineconst Versionbump. 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.0on/healthfrom 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 ofsdkcompatbefore the platform is tagged — a/healthrecommending a version nobody can install is the v9.7.0 phantom-version incident.Checks
go build ./...clean andgo test ./...green on the committed head — expected, since no source file is touched.version.go'sconst Versionis the on-wiresdk-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.goandCHANGELOG.mdonly.version.gois 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 inruntime-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) andchore(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:84—expected := "sdk-go/" + axonflow.Version, then asserts the live agent echoes that exact string back in itsscope_mismatchresponse.This SDK has exactly ONE version site,
version.go'sconst 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.