fix(release): a changelog problem must never fail a release (+ rotate 0.3.5/0.3.6) - #187
Merged
Conversation
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
approved these changes
Sep 1, 2026
dirvine
left a comment
Member
There was a problem hiding this comment.
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.
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.
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
No Rust code is touched. Two files: the release workflow and
CHANGELOG.md.Compatibility
Semver impact
Test evidence
Both parts verified locally against the modified files; there is no runtime code to test.
Part 1 — the workflow. The
extract changelog entrystep was pulled out of the YAMLand run as a standalone script with the version substituted, once per case:
versioninput0.3.6-rc.1## [0.3.6]section0.3.6-beta.10.3.60.3.50.3.49.9.9(no section)::warning title=Missing changelog section::…, placeholder body naming9.9.9So 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_loadparses the workflow (jobsbuild,sign-windows,sign-releases,release), andbash -non the extracted step passes.Part 2 — the changelog.
diffconfirms the five moved entries are byte-identical to their pre-move text, with thesingle exception of
(#140)→(#172).## [0.3.4]is at new line 38 — nothing at or belowit changed.
New dependency
none
ADR
n/a (Tier 0)
Mitigation / rollback
git reverteither commit independently — they touch disjoint files. Reverting the workflowcommit 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 isthe 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 everyrelease's notes, and it is kept; (2)
exit 1when 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 aplaceholder body. ant-client was the last repo violating this rule; saorsa-transport's
changelog step is
continue-on-error: trueand 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-01opens 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-coreversiontriple: at rc.1 those are
git+branchrefs 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 upstreamPR are the durable parts.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Nhag7h3fagNA6fqUg6gAmZ