Skip to content

chore(release): land 1.5.0 and anchor squash-landed releases - #1580

Merged
Martin Torp (mtorp) merged 2 commits into
v1.xfrom
martin/v1x-cleanup-broken-releases
Oct 7, 2026
Merged

Martin Torp (mtorp) merged 2 commits into
v1.xfrom
martin/v1x-cleanup-broken-releases

Conversation

@mtorp

@mtorp Martin Torp (mtorp) commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

Cleanup for the two v1.x releases that broke when v1.x got branch protection. The process fix itself is in #1579.

What's broken

Version On npm Tag v1.x
1.4.2 yes v1.4.2 at 8bfe7d4, off v1.x landed by hand as #1577 (5e0466d, a different SHA)
1.5.0 yes v1.5.0 at faf8b5f, off v1.x missing. v1.x still says 1.4.2

The repo only allows squash merges and tag protection blocks moving v* tags. So neither tag can ever be reachable from v1.x.

What this PR does

  1. Lands 1.5.0 on v1.x. It applies the same package.json and CHANGELOG change as faf8b5f, so v1.x matches what shipped.
  2. Fixes the changelog anchor. scripts/release/history.mts anchors the next release's changelog range to the newest release tag reachable from HEAD. Today that's v1.4.1. The next bump would re-count every commit from 1.4.2 and 1.5.0, including the feat: from 📣🤖 feat(fix): add opt-in --allow-overrides flag #1573, and derive 1.6.0 with a changelog that repeats old entries. Now, when a tagged version isn't reachable, the code finds the first-parent commit that set package.json to that version and uses it as the landed release and the range start. This doesn't depend on the merge commit's title.

Checked against the real tags:

  • On today's v1.x the anchor resolves to 5e0466d, the 1.4.2 squash commit.
  • On this branch it resolves to the 1.5.0 landing commit.
  • bump.mts --dry-run derives 1.5.1 with an empty range.

With #1579, future release PRs get tagged after they're squash-merged, so their tags will be reachable. This fallback only matters for releases landed by squash before that, which today means 1.4.2 and 1.5.0.

After merge

The npm-publish-v1.4.2 and npm-publish-v1.5.0 branches are leftovers from the failed runs. Both tags point at the same commits, so the branches can be deleted safely.

Expected reviewer effort: High-level design decisions


Note

Medium Risk
Changes release versioning and changelog derivation logic; incorrect anchoring could mis-bump versions or duplicate changelog entries, though behavior is covered by new tests.

Overview
Lands v1.5.0 on the protected release line by bumping package.json to 1.5.0 and promoting the existing Unreleased changelog (including socket fix --allow-overrides and Coana 15.12.0) into a dated 1.5.0 section.

Fixes release bump/changelog anchoring when release tags sit on commits that are not reachable from HEAD (e.g. squash merges with immovable v* tags). Release history now treats anchorRef as either the newest merged tag or the first-parent commit whose package.json version matches an unreachable tag; bump.mts uses that ref for the commit range so the next version/changelog section does not re-scan already-shipped work.

Adds a git fixture test for the off-line-tag squash case and updates existing tests for the renamed anchorRef field.

Reviewed by Cursor Bugbot for commit 4e71152. Configure here.

1.5.0 is tagged and published, but the publish run could not move v1.x
to its bump commit after branch protection landed. This applies the same
version and changelog change so v1.x matches what shipped.
v1.x only accepts squash merges, so a release bump landed through a PR
gets a new SHA and its tag stays on a commit outside the release line.
That is already true for 1.4.2 and 1.5.0. Without this, the next bump
anchors to v1.4.1, re-counts their commits, and derives a minor.

Tagged versions that are not reachable now resolve to the first-parent
commit that set package.json to that version, and the changelog range
starts there.
@mtorp
Martin Torp (mtorp) merged commit cd69927 into v1.x Oct 7, 2026
16 checks passed
@mtorp
Martin Torp (mtorp) deleted the martin/v1x-cleanup-broken-releases branch October 7, 2026 06:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants