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
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.
Cut the release in the GitHub UI — Releases → Draft a new release → Choose a tag → type 2.1.0 → Create 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.)
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.
Execute the first
v2/main→mainmilestone merge and cut the v2.1.0 release.Everything is built and staged in PR #1903 — merge resolved, version bumped,
npm run cigreen. Only the steps below remain.Runbook
build.git push origin mainis rejected —mainis ruleset-protected (two rulesets on~DEFAULT_BRANCH; one grants bypass to nobody, admins included). Same reason nothing can be pushed tomaindirectly, including a version bump — which is why the bump already rides chore: merge v2/main for the v2.1.0 milestone release #1903 asdedee5af.2.1.0→ Create new tag on publish, Target =main→ Publish.Publishing is what publishes to npm: the
publishjob is gated ongithub.event_name == 'release', runspack:verify, asserts the tag matchespackage.json, and pushes thelatestdist-tag. (A tag push alone runsbuildbut never publishes.)>=22.7.5→>=22.19.0, fix(core): mirror SEP-2243 x-mcp-header args to Mcp-Param-* on tools/call #1847 (tools/callnow sends the SEP-2243Mcp-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.References, notCloses.Then verify
@claudeworks again — comment@claude reviewon any open PR. Workflows forissue_commentrun from the default branch, so ci: restore the Claude Code workflow and .mcp.json, lost in the v2 tree swap #1869 was inert until this merge.v2/main, and security updates still appear (they ran whiledependabot.ymlwas missing — build(deps): bump the npm_and_yarn group across 5 directories with 12 updates #1833, build(deps): bump the npm_and_yarn group across 5 directories with 2 updates #1840 — buttarget-branchaffects security-update behavior, so confirm).Two things not to undo
Never back-merge
mainintov2/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 frommain: GitHub's web conflict editor commits to the head branch, which would have done exactly that.Never
--allow-unrelated-histories. The branches share merge base4d30d1cd, established by the go-live merge (#1830).After this, it's self-sustaining
Once
v2/main's tip is an ancestor ofmain, andmainmakes 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 wheremainheld contentv2/mainlacked. A normal milestone needs none of that.