[GH-ISSUE #1063] [Bug] Validate checkpoint release versions and unreleased breaking changes before tagging #389

Closed
opened 2026-10-15 18:24:35 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @N0zoM1z0 on GitHub (Oct 8, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1063

Before submitting

  • Searched open and closed issues for a related report.
  • No credentials, private target paths or sensitive artifacts are included.

Area

Setup, packaging, or upgrade — release workflow.

Observed behavior

Preparing release/6.0.0 at source 163ee09a7425479385e0ed0b5d74043e2587eab2 generated PR #1058 proposing 5.1.0, with 15 unreleased mainline entries omitted, including the breaking MCP path changes #948 and #1004. The workflow accepted a mismatch between the branch's intended version and the generated candidate.

The 6.0.0 release was corrected manually, reviewed, tested and successfully published from 6fee42689ae6e95a0182e0d4d0f55644e73e72be; no incorrect 5.1.0 package was published.

Reproduction

  1. Cut a frozen release from main, while main continues accepting commits.
  2. Publish the frozen release and merge its tag/metadata back into the newer main.
  3. Cut the next checkpoint and run release.yml with phase=prepare.
  4. Compare the bot's selected history with the actual Git ancestry range from the published baseline tag to the checkpoint.

Executed evidence: prepare run 37755874269, initial PR #1058. Its chronological history prefix contained 42 commits; the actual ancestry range also contained the older mainline changes omitted at that cutoff.

Expected behavior

  • release/VERSION expresses an explicit expected SemVer. Candidate and publication metadata must match it before a tag is created.
  • Inspect actual ancestry from the published baseline to the selected checkpoint. Explicit unreleased breaking markers must remain visible in migration notes and version review even when the bot's chronological history scan omits them.
  • Preserve manual prepare/publish, fixed source/provenance, package verification and registry canary.
  • Define compatible patch/minor changes and require concrete old/new usage plus migration reasoning before marking a public CLI/MCP change breaking. Prefer compatibility/deprecation transitions.

Impact and scope

Maintainer release correctness: wrong version proposals and incomplete notes can otherwise conceal incompatible public API changes. No runtime reverse-engineering feature change is required. Sync the successful 6.0.0 baseline and tag ancestry back to main as part of this maintenance.

REA version

Source 163ee09a; workflow also present in 6.0.0. Release Please 17.3.0 via action 5c625bfb5d1ff62eadeeb3772007f7f66fdcf071.

Runtime and platform

GitHub Actions Ubuntu x64, Node 24.18.0; independent local Git history reproduction on Linux x64.

Target and artifact context

REA release branches, version metadata and changelog; no private binary/game fixtures.

Interface

Package or setup — GitHub Actions maintenance.

Earliest failure stage

Release preparation/version and history validation, before public publication.

Analysis

Source inspection confirms the upstream manifest walker stops when it encounters the last released side-branch SHA in chronological history. The ancestry-set difference can contain additional mainline commits before that point. Release Please remains the release generator; REA needs explicit validation around its proposed result.

Proposed regression coverage

A deterministic Git DAG with a late-created side-branch release tag, unreleased mainline breaking changes, metadata/version mismatch, missing migration notes, valid major/minor/patch candidates and workflow guards that execute before tag creation.

Originally created by @N0zoM1z0 on GitHub (Oct 8, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1063 ### Before submitting - [x] Searched open and closed issues for a related report. - [x] No credentials, private target paths or sensitive artifacts are included. ### Area Setup, packaging, or upgrade — release workflow. ### Observed behavior Preparing `release/6.0.0` at source `163ee09a7425479385e0ed0b5d74043e2587eab2` generated PR #1058 proposing 5.1.0, with 15 unreleased mainline entries omitted, including the breaking MCP path changes #948 and #1004. The workflow accepted a mismatch between the branch's intended version and the generated candidate. The 6.0.0 release was corrected manually, reviewed, tested and successfully published from `6fee42689ae6e95a0182e0d4d0f55644e73e72be`; no incorrect 5.1.0 package was published. ### Reproduction 1. Cut a frozen release from main, while main continues accepting commits. 2. Publish the frozen release and merge its tag/metadata back into the newer main. 3. Cut the next checkpoint and run `release.yml` with `phase=prepare`. 4. Compare the bot's selected history with the actual Git ancestry range from the published baseline tag to the checkpoint. Executed evidence: [prepare run 37755874269](https://github.com/morluto/rea/actions/runs/37755874269), initial PR #1058. Its chronological history prefix contained 42 commits; the actual ancestry range also contained the older mainline changes omitted at that cutoff. ### Expected behavior - `release/VERSION` expresses an explicit expected SemVer. Candidate and publication metadata must match it before a tag is created. - Inspect actual ancestry from the published baseline to the selected checkpoint. Explicit unreleased breaking markers must remain visible in migration notes and version review even when the bot's chronological history scan omits them. - Preserve manual prepare/publish, fixed source/provenance, package verification and registry canary. - Define compatible patch/minor changes and require concrete old/new usage plus migration reasoning before marking a public CLI/MCP change breaking. Prefer compatibility/deprecation transitions. ### Impact and scope Maintainer release correctness: wrong version proposals and incomplete notes can otherwise conceal incompatible public API changes. No runtime reverse-engineering feature change is required. Sync the successful 6.0.0 baseline and tag ancestry back to main as part of this maintenance. ### REA version Source 163ee09a; workflow also present in 6.0.0. Release Please 17.3.0 via action 5c625bfb5d1ff62eadeeb3772007f7f66fdcf071. ### Runtime and platform GitHub Actions Ubuntu x64, Node 24.18.0; independent local Git history reproduction on Linux x64. ### Target and artifact context REA release branches, version metadata and changelog; no private binary/game fixtures. ### Interface Package or setup — GitHub Actions maintenance. ### Earliest failure stage Release preparation/version and history validation, before public publication. ### Analysis Source inspection confirms the upstream manifest walker stops when it encounters the last released side-branch SHA in chronological history. The ancestry-set difference can contain additional mainline commits before that point. Release Please remains the release generator; REA needs explicit validation around its proposed result. ### Proposed regression coverage A deterministic Git DAG with a late-created side-branch release tag, unreleased mainline breaking changes, metadata/version mismatch, missing migration notes, valid major/minor/patch candidates and workflow guards that execute before tag creation.
Author
Owner

@N0zoM1z0 commented on GitHub (Oct 8, 2026):

Fixed and merged in #1064 (8a31508c). The final head passed 67 focused local tests and all 32 GitHub checks; the merge-title finding was reproduced and fixed before merging.

Post-merge checks confirm:

  • main includes the published 6.0.0 tag as an ancestor, with later #1059 changes preserved;
  • package/lock/manifest/MCP registry metadata agree on 6.0.0;
  • the actual merged GitHub PR title is recognized by the guard, and a read-only 6.0.1 preparation check succeeds against merged main;
  • the historical wrong 5.1.0 bot candidate is rejected and both original breaking commits are retained.

The expanded audit also identified two non-breaking 6.0.0 changelog omissions (#994/#996), reviewed as warnings; both application changes are already included. The published 6.0.0 source remains unchanged. No additional release was created.

<!-- gh-comment-id:6057944581 --> @N0zoM1z0 commented on GitHub (Oct 8, 2026): Fixed and merged in #1064 (`8a31508c`). The final head passed 67 focused local tests and all 32 GitHub checks; the merge-title finding was reproduced and fixed before merging. Post-merge checks confirm: - main includes the published 6.0.0 tag as an ancestor, with later #1059 changes preserved; - package/lock/manifest/MCP registry metadata agree on 6.0.0; - the actual merged GitHub PR title is recognized by the guard, and a read-only 6.0.1 preparation check succeeds against merged main; - the historical wrong 5.1.0 bot candidate is rejected and both original breaking commits are retained. The expanded audit also identified two non-breaking 6.0.0 changelog omissions (#994/#996), reviewed as warnings; both application changes are already included. The published 6.0.0 source remains unchanged. No additional release was created.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#389
No description provided.