Originally created by: Akarsh-Hegde
mainA normal merge cannot fix the problem: semantic-release computes the version from every commit message since the last tag (v1.51.0), and the BREAKING CHANGE footer is baked into the already-merged commit 3b4ff4d. Merging this branch forward would leave that footer in range → it would still cut 2.0.0. The footer can only be removed by replacing main's history.
feat(observability)!: deprecate MERIDIAN_OO_AUTH commit (! + BREAKING CHANGE: footer) made semantic-release bump major → 2.0.0.git push --tags (a transient GitHub HTTP 500), so nothing shipped — no v2.0.0 tag, no npm publish, no GitHub release. Only the chore(release): 2.0.0 commit (0deb06f) landed on main.The exact 12 commits of [#271], rebuilt linearly on v1.51.0 (40bd410), with:
feat(observability): (dropped ! and the BREAKING CHANGE: footer) — code unchangedchore(release): 2.0.0 commit dropped (manifests + CHANGELOG back at 1.51.0)Verification: git diff <this-branch> ce88c17 is empty — the tree is byte-identical to the merged code that already passed CI + a full 362-test local run. Only commit messages/SHAs changed.
git fetch origin
git push --force-with-lease=main:0deb06fff2c63e2a8730b44268c38fcc8baff6c3 \
origin origin/fix/release-history-1.52:main
--force-with-lease aborts unless main is still at the broken 0deb06f, so it can't clobber a newer push. After it lands, the push (no [skip ci]) triggers the release workflow → semantic-release sees only feat/fix since v1.51.0 → ships 1.52.0.
Backup of the current (broken) main is kept locally as backup/main-pre-relfix → 0deb06f.
🤖 Generated with Claude Code
Ticket changed by: Akarsh-Hegde