Skip to content

fix(release): a changelog problem must never fail a release (+ rotate 0.3.5/0.3.6) - #187

Merged
jacderida merged 2 commits into
WithAutonomi:mainfrom
jacderida:chrisoneil/v2-1142-ant-client-a-changelog-problem-must-never-fail-a-release
Sep 1, 2026
Merged

fix(release): a changelog problem must never fail a release (+ rotate 0.3.5/0.3.6)#187
jacderida merged 2 commits into
WithAutonomi:mainfrom
jacderida:chrisoneil/v2-1142-ant-client-a-changelog-problem-must-never-fail-a-release

Conversation

@jacderida

Copy link
Copy Markdown
Member

Linear issue

V2-1142 — https://linear.app/autonominetwork/issue/V2-1142

Blocks V2-1134 (Release Train — 2026-09-01) / V2-1135 (Cut rc.1).

Risk tier

  • T0 — docs / tooling / CI / pure UX-output. Repo CI only.
  • T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
  • T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
  • T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

No Rust code is touched. Two files: the release workflow and CHANGELOG.md.

Compatibility

  • Wire: none
  • Storage: none
  • API: none

Semver impact

  • breaking
  • feature
  • fix

Test evidence

Both parts verified locally against the modified files; there is no runtime code to test.

Part 1 — the workflow. The extract changelog entry step was pulled out of the YAML
and run as a standalone script with the version substituted, once per case:

version input Result
0.3.6-rc.1 exit 0, 10-line body — the ## [0.3.6] section
0.3.6-beta.1 exit 0, byte-identical to the rc.1 body
0.3.6 exit 0, byte-identical to the rc.1 body
0.3.5 exit 0, 14-line body — the five rotated entries
0.3.4 exit 0, 3-line body, unchanged from before
9.9.9 (no section) exit 0, ::warning title=Missing changelog section::…, placeholder body naming 9.9.9

So the version-matched extraction is unchanged where a section exists, and the missing-section
case now warns and publishes instead of exit 1.

Also: yaml.safe_load parses the workflow (jobs build, sign-windows, sign-releases,
release), and bash -n on the extracted step passes.

Part 2 — the changelog.

  • diff confirms the five moved entries are byte-identical to their pre-move text, with the
    single exception of (#140)(#172).
  • The last diff hunk ends at new line 26; ## [0.3.4] is at new line 38 — nothing at or below
    it changed.

New dependency

none

ADR

n/a (Tier 0)

Mitigation / rollback

git revert either commit independently — they touch disjoint files. Reverting the workflow
commit restores the fail-closed guard; reverting the changelog commit restores the previous
section layout. Neither affects any shipped artifact, only the text of a GitHub release body.


What's in here

Part 1 — a changelog problem must never fail a release. PR #183 added a fail-closed guard
to .github/workflows/ant-cli-release.yml. It did two separable things and only the first is
the V2-1107 fix: (1) extract the section matching the version being released rather than
blindly taking the first section — this is what stopped [Unreleased] shipping as every
release's notes, and it is kept; (2) exit 1 when that section is missing or empty —
removed. Dropping (2) regresses nothing V2-1107 was about: with (1) in place and no section
present the result is empty notes, not stale ones. The hard failure only converted "missing
notes" into "no release at all", which is strictly worse — the artifacts are fine and the
omission is fixable with gh release edit. The step now emits a ::warning:: annotation and a
placeholder body. ant-client was the last repo violating this rule; saorsa-transport's
changelog step is continue-on-error: true and ant-protocol's is a plain link.

Pre-tag enforcement is deliberately not added here. If we want it, it belongs on the
release-prep PR where a fix is cheap and nothing is blocked — a separate follow-up.

Part 2 — fix the changelog content. The five entries under [Unreleased] are 0.3.5's work
(promoted 2026-08-31, ad09c57); they move verbatim under ## [0.3.5] - 2026-08-31.
[Unreleased] becomes a bare heading and ## [0.3.6] - 2026-09-01 opens for this train.
(#140)(#172) (#140 is a saorsa-transport PR; V2-1068's manifest gives #172), and #174
(NetworkHealth / V2-1037) gets the 0.3.5 entry it shipped without.

0.3.6's Fixed entry deliberately omits the saorsa-core / ant-protocol / ant-core version
triple: at rc.1 those are git+branch refs and only become literal pins at promotion, and one
## [0.3.6] section is shared by the rc, beta and stable builds. The behaviour and the upstream
PR are the durable parts.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Nhag7h3fagNA6fqUg6gAmZ

jacderida and others added 2 commits September 1, 2026 14:10
A missing or empty CHANGELOG entry must never block a release. Release-
blocking is for correctness and safety, not editorial omissions, and
ant-client was the only repo violating that: saorsa-transport's changelog
step is `continue-on-error: true` and ant-protocol's is a plain link in
the release body.

PR WithAutonomi#183 did two separable things, and only the first is the V2-1107 fix:

1. Extract the section matching the version being released, instead of
   blindly taking the first section. This is what stopped `[Unreleased]`
   shipping as every release's notes (0.3.4's body was byte-identical to
   0.3.3's). Kept, unchanged.
2. `exit 1` when that section is missing or empty. Removed.

Dropping (2) regresses nothing V2-1107 was about: with (1) in place and
no section present the result is *empty* notes, not *stale* ones. The
hard failure only converted "missing notes" into "no release at all",
which is strictly worse — the artifacts are fine and the omission is
fixable after the fact with `gh release edit`.

The step now emits a `::warning::` annotation, so the omission stays
loud on the workflow run, and writes a placeholder body naming the
version. If we still want enforcement it belongs *before* the tag, on
the release-prep PR, where a fix is cheap and nothing is blocked; that
is a separate follow-up and deliberately not in this change.

V2-1142

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nhag7h3fagNA6fqUg6gAmZ
The five entries under `[Unreleased]` are 0.3.5's work, which promoted on
2026-08-31 (ad09c57). They move verbatim under `## [0.3.5] - 2026-08-31`;
`[Unreleased]` is left as a bare heading and a new `## [0.3.6] -
2026-09-01` opens for the 2026-09-01 train.

Two corrections folded in:

- The resumable external-signer finalize entry cited (WithAutonomi#140), which is a
  saorsa-transport PR. Per V2-1068's manifest the ant-client PR is WithAutonomi#172.
- WithAutonomi#174 (NetworkHealth snapshot + write-readiness formula in ant-core,
  V2-1037) shipped in 0.3.5 with no entry; it gets one under 0.3.5.

0.3.6's Fixed entry deliberately omits the saorsa-core / ant-protocol /
ant-core version triple: at rc.1 those are git+branch refs and only
become literal pins at promotion, and one `## [0.3.6]` section is shared
by the rc, beta and stable builds. The behaviour and the upstream PR are
the durable parts.

No entry text is reworded — only moved — apart from WithAutonomi#140 -> WithAutonomi#172, and
nothing at or below `## [0.3.4]` changes.

V2-1142

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nhag7h3fagNA6fqUg6gAmZ

@dirvine dirvine left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed exact head 75825ad6d8ef7e7e9a737fcd0cf5a6f980b8731a (lightweight workflow review as requested). Verified the workflow parses with PyYAML, the extracted shell passes bash -n, and local release-note extraction succeeds for 0.3.6-rc.1, 0.3.5, and a missing-section fallback (warning + placeholder, exit 0). Diff is clean; no blocking issues found.

@jacderida
jacderida merged commit 246e9f5 into WithAutonomi:main Sep 1, 2026
13 of 15 checks passed
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.

2 participants