Skip to content

Execute the first v2/main → main milestone merge and cut the release #1876

Description

@cliffhall

Execute the first v2/mainmain milestone merge and cut the v2.1.0 release.

Everything is built and staged in PR #1903 — merge resolved, version bumped, npm run ci green. Only the steps below remain.

Runbook

  1. Approve chore: merge v2/main for the v2.1.0 milestone release #1903 — 1 review required, from someone other than the author (Copilot's doesn't count). Wait for build.
  2. Merge it with the button, using Create a merge commit. A local merge + git push origin main is rejected — main is ruleset-protected (two rulesets on ~DEFAULT_BRANCH; one grants bypass to nobody, admins included). Same reason nothing can be pushed to main directly, including a version bump — which is why the bump already rides chore: merge v2/main for the v2.1.0 milestone release #1903 as dedee5af.
  3. Cut the release in the GitHub UI — Releases → Draft a new release → Choose a tag → type 2.1.0Create new tag on publish, Target = main → Publish.
    Publishing is what publishes to npm: the publish job is gated on github.event_name == 'release', runs pack:verify, asserts the tag matches package.json, and pushes the latest dist-tag. (A tag push alone runs build but never publishes.)
  4. Release notes — the Node engine floor >=22.7.5>=22.19.0, fix(core): mirror SEP-2243 x-mcp-header args to Mcp-Param-* on tools/call #1847 (tools/call now sends the SEP-2243 Mcp-Param-* headers), and the issues-only contribution model (docs: replace the markdown bug template with GitHub issue forms #1894, docs: rename CONTRIBUTORS.md to CONTRIBUTING.md so GitHub surfaces the policy #1884). Those are the only user-visible changes; the rest is repo infrastructure. Full payload: milestone overview.
  5. Close this issue manuallychore: merge v2/main for the v2.1.0 milestone release #1903 says References, not Closes.

Then verify

Two things not to undo

Never back-merge main into v2/main. Built and rejected — #1868 (closed). It would pull 224 commits, 212 of them pre-swap v1-tree commits, permanently into the develop branch's ancestry. This is also why #1903's conflicts were resolved on a branch cut from main: GitHub's web conflict editor commits to the head branch, which would have done exactly that.

Never --allow-unrelated-histories. The branches share merge base 4d30d1cd, established by the go-live merge (#1830).

After this, it's self-sustaining

Once v2/main's tip is an ancestor of main, and main makes no content changes of its own, every subsequent milestone merge is conflict-free. This one was the exception: the branches had only just acquired a shared history, two PRs (#1880, #1881) existed purely to shrink the conflict set, and #1904 closed the last file where main held content v2/main lacked. A normal milestone needs none of that.

Metadata

Metadata

Assignees

Labels

v2Issues and PRs for v2

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions