Summary
Bump the root package.json version 2.2.0 → 2.3.0 on v2/main, as the first step of the v2.3.0 release.
This is the first release through the procedure established in #2010 / #2011, where the bump happens on v2/main before the milestone merge rather than on the milestone-merge branch afterwards. Doing it in the wrong order is what left v2/main stranded at 2.0.0 through two releases, so this issue exists to make step 1 explicit and hard to skip.
Step 1 — the bump (this issue)
git checkout -b v2/chore/<this-issue>-bump-2-3-0 v2/main
npm version minor --no-git-tag-version
# PR → v2/main
⚠️ --no-git-tag-version is required. A bare npm version also creates a tag, and it would land on a v2/main commit — but the release is cut from main, so the tag belongs on the merge commit there (step 3). Tagging here produces a tag on a commit that is never released. It would also be v-prefixed, which does not match this repo's bare x.y.z tags.
Expected diff — two files, three lines:
package.json | 2 +- "version": "2.2.0" → "2.3.0"
package-lock.json | 4 ++-- top-level `version` AND packages[""].version
Then (not this issue)
-
Merge v2/main → main through the usual milestone-merge branch. It now carries the bump.
-
Tag origin/main and draft the Release:
git fetch origin main
git tag 2.3.0 origin/main && git push origin 2.3.0
⚠️ Tag origin/main, not a local HEAD after git checkout main && git pull — pull follows your configured merge/rebase strategy, so a divergent local main can produce a local commit, and git push origin <tag> pushes only the tag. That yields a release pointing at a commit nobody else has, and the publish job would not catch it (its tag-vs-package.json assertion still passes on a locally-merged commit).
Full procedure: Cutting a release.
Sanity checks
- Between step 1 and step 2,
v2/main and main legitimately differ — v2/main on the version being built, main on the released one. Ahead is expected; behind means something went wrong.
- After the release, confirm they agree:
git show origin/v2/main:package.json | grep version and the same for origin/main.
- Nothing in the repo asserts a specific version value, so the bump is a safe two-file change with no test impact.
Summary
Bump the root
package.jsonversion 2.2.0 → 2.3.0 onv2/main, as the first step of the v2.3.0 release.This is the first release through the procedure established in #2010 / #2011, where the bump happens on
v2/mainbefore the milestone merge rather than on the milestone-merge branch afterwards. Doing it in the wrong order is what leftv2/mainstranded at2.0.0through two releases, so this issue exists to make step 1 explicit and hard to skip.Step 1 — the bump (this issue)
--no-git-tag-versionis required. A barenpm versionalso creates a tag, and it would land on av2/maincommit — but the release is cut frommain, so the tag belongs on the merge commit there (step 3). Tagging here produces a tag on a commit that is never released. It would also bev-prefixed, which does not match this repo's barex.y.ztags.Expected diff — two files, three lines:
Then (not this issue)
Merge
v2/main→mainthrough the usual milestone-merge branch. It now carries the bump.Tag
origin/mainand draft the Release:git fetch origin main git tag 2.3.0 origin/main && git push origin 2.3.0origin/main, not a localHEADaftergit checkout main && git pull—pullfollows your configured merge/rebase strategy, so a divergent localmaincan produce a local commit, andgit push origin <tag>pushes only the tag. That yields a release pointing at a commit nobody else has, and the publish job would not catch it (its tag-vs-package.jsonassertion still passes on a locally-merged commit).Full procedure: Cutting a release.
Sanity checks
v2/mainandmainlegitimately differ —v2/mainon the version being built,mainon the released one. Ahead is expected; behind means something went wrong.git show origin/v2/main:package.json | grep versionand the same fororigin/main.