You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Surfaced cutting v1.2.0 (the first release under the dev/main release-cut model — AgDR-0007). The release flow is:
Daily PRs land on dev (no CHANGELOG entry per-PR).
Release PR (e.g. release/v1.2.0) branches off dev, adds the CHANGELOG entry, and squash-merges to main.
After step 2, main has the v1.2.0 CHANGELOG section but dev does not. The release branch's CHANGELOG commit was merged into main; dev's working tree is unchanged. The next release PR cut from dev would build a v1.3.0 section on top of v1.1.0 (skipping v1.2.0 entirely from dev's running history) unless the operator manually re-fetches main's CHANGELOG first.
This is a real flaw in the dev/main flow as currently implemented. AgDR-0007 didn't anticipate this side-effect.
Scope
Two complementary fixes:
A. Sync dev's CHANGELOG.md to match main (immediate)
One-file commit on a chore/... branch off dev. Copy CHANGELOG.md from upstream/main to dev so the v1.2.0 section is present on both branches. The diff is exactly the new v1.2.0 section being prepended to dev's existing CHANGELOG.
B. Update /release skill to source the previous CHANGELOG from main (longer-term)
The /release skill's step 3 ("Generate the CHANGELOG draft") currently reads from dev's tip when computing the new entry's position. After this PR lands, the next release cut should:
Fetch upstream/main's CHANGELOG.md
Prepend the new release's section to that
OR back-merge main → dev before generating the draft
Either approach prevents the same drift from recurring next release. Worth picking one and updating the skill.
Acceptance Criteria
dev's CHANGELOG.md matches upstream/main's CHANGELOG.md exactly after this PR merges
Spot-check: the v1.2.0 section is present at the top of dev's CHANGELOG, followed by v1.1.0, v1.0.0, etc. — same ordering as main
No other file changes in the PR (single-file scope)
Follow-up scope (B) captured in the PR description as "next ticket" so it doesn't get lost
Risks / Dependencies
Tiny scope. Single-file copy.
No mechanism change. Pure history-sync between two branches the framework owns.
Refs AgDR-0007 — the release-cut model decision; this fix is a missed corollary of that decision.
Driver
Surfaced cutting v1.2.0 (the first release under the dev/main release-cut model — AgDR-0007). The release flow is:
dev(no CHANGELOG entry per-PR).release/v1.2.0) branches offdev, adds the CHANGELOG entry, and squash-merges tomain.After step 2,
mainhas the v1.2.0 CHANGELOG section butdevdoes not. The release branch's CHANGELOG commit was merged into main;dev's working tree is unchanged. The next release PR cut fromdevwould build av1.3.0section on top ofv1.1.0(skippingv1.2.0entirely from dev's running history) unless the operator manually re-fetches main's CHANGELOG first.This is a real flaw in the dev/main flow as currently implemented. AgDR-0007 didn't anticipate this side-effect.
Scope
Two complementary fixes:
A. Sync
dev'sCHANGELOG.mdto matchmain(immediate)One-file commit on a
chore/...branch offdev. CopyCHANGELOG.mdfromupstream/mainto dev so the v1.2.0 section is present on both branches. The diff is exactly the new v1.2.0 section being prepended to dev's existing CHANGELOG.B. Update
/releaseskill to source the previous CHANGELOG frommain(longer-term)The
/releaseskill's step 3 ("Generate the CHANGELOG draft") currently reads from dev's tip when computing the new entry's position. After this PR lands, the next release cut should:upstream/main'sCHANGELOG.mdmain → devbefore generating the draftEither approach prevents the same drift from recurring next release. Worth picking one and updating the skill.
Acceptance Criteria
dev'sCHANGELOG.mdmatchesupstream/main'sCHANGELOG.mdexactly after this PR mergesRisks / Dependencies