fix(ci): accept release/vX.Y maintenance branches in release-notes validation

[insipx]

Found by the adversarial review of the 1.11.0 postmortem: renaming the release branch to release/v1.11 (matching the release/v1.9/release/v1.10 maintenance convention) broke the release-notes workflow for it — the validate step required exactly release/X.Y.Z, so any future drafting run on this branch (e.g. for a 1.11.1 patch) would error out immediately.

Changes in release-notes.yml:

• Widen validation to accept both shapes: pipeline-created release/X.Y.Z[-suffix] and maintenance lines release/vX.Y[.Z]. Still rejects main, release/foo, release/v1 (tested all shapes).
• Version extraction strips the optional v. The extracted value is label-only downstream (commit messages, PR titles, the ai-release-notes/* suggestion branch name), so a partial 1.11 is fine — noted in a comment.

Audit of other parsers: release.yml only checks the release/ prefix (already fine — it's why the final release ran from the renamed branch), and create-release-branch constructs release/${version} without parsing. This regex was the only strict one.

🤖 Generated with Claude Code

Note

Fix release-notes CI to accept release/vX.Y maintenance branches in branch validation

• Updates the branch validation regex in release-notes.yml to accept both release/X.Y.Z and release/vX.Y (with optional patch) formats.
• Strips a leading v from the extracted version after removing the release/ prefix, so the emitted version output is always numeric (e.g. 1.11 not v1.11).

^{Macroscope summarized 1e4d82f.}

[claude]

Claude finished @insipx's task —— View job

---

Code Review — July 29, 2026 17:57 UTC

Todo List:

• Read and analyze the workflow file changes
• Review regex pattern correctness
• Check for edge cases and potential bugs
• Provide final feedback

---

Summary

The changes are correct and well-documented. The regex properly handles both branch formats, and the version extraction logic is sound.

Detailed Analysis

Regex Pattern (.github/workflows/release-notes.yml:71)

^release/v?[0-9]+\.[0-9]+(\.[0-9]+)?(-[a-zA-Z0-9.]+)?$

✅ Correctly accepts:

• release/1.11.0 (pipeline format)
• release/v1.11 (maintenance line)
• release/v1.11.0 (maintenance with patch)
• release/1.11.0-rc.1 (with suffix)

✅ Correctly rejects:

• main
• release/foo
• release/v1 (incomplete version)
• release/1 (incomplete version)

Version Extraction (lines 83-84)

VERSION="${BRANCH#release/}"
VERSION="${VERSION#v}"

✅ The v prefix stripping is correct and the comment explains that partial versions like 1.11 are acceptable for the downstream label use cases (commit messages, PR titles, branch names).

Minor Observations

1. Documentation: The inline comments (lines 69-70, 81-82) clearly explain the two branch formats and the downstream usage, which is excellent for maintainability.

2. Consistency: The error message (line 72) helpfully shows both accepted formats, making debugging easier for users.

3. No Breaking Changes: Existing release/X.Y.Z branches continue working unchanged.

Conclusion

No issues found. The fix is minimal, targeted, and properly addresses the stated problem without introducing new risks.

---

[macroscopeapp]

Approvability

Verdict: Approved 1e4d82f

Minor CI workflow change that relaxes branch name validation to accept maintenance branch formats. The author owns this workflow file. No production runtime impact - only affects which branch names pass release notes validation.

^{You can customize Macroscope's approvability policy. Learn more.}