Problem
The release protocol's step 7 handles publish ordering (core/types before codev) and idempotency well, but relies on human judgment for "if you've changed `packages/core/src/**`, bump core's version before publishing". When that step is missed, the drift bug from 0602 recurs:
- Core source changes (e.g. `tower-client.ts` gains a new method).
- Human forgets to bump `packages/core/package.json`.
- `pnpm publish --filter @cluesmith/codev-core` skips silently (version unchanged, idempotent — no error).
- `cd packages/codev && pnpm publish` runs; `workspace:*` rewrites to the unchanged core version.
- Tarball ships with `"@cluesmith/codev-core": "0.0.1"` while the new codev code expects the new API.
- End user runs `npm install -g @cluesmith/codev@latest` → `client.getSomething is not a function`.
A smaller second bug: even when core is bumped, nothing forces `dist/` to be rebuilt before publish. Stale `dist/` can ship (documented in `codev/specs/0602-codev-core-exports-issue.md`).
Proposed fix
Two small changes, ~20 lines of work total:
- `scripts/bump-all.sh` — one command that sets every publishable package (`codev`, `codev-core`, `codev-types`, `codev` VS Code extension) to the same version. Run at release time instead of thinking about which packages need bumping. Drift becomes mechanically impossible.
- `"prepublishOnly": "pnpm build"` on `packages/core/package.json` — guarantees fresh `dist/` whenever core is published.
Plus:
- Root `package.json` gets a `"bump-version": "scripts/bump-all.sh"` alias.
- One-sentence addition to release protocol step 4 pointing at `pnpm bump-version X.Y.Z`.
- One-time alignment commit during the next release to catch up `codev-core` (`0.0.1`), `codev-types` (`0.0.1`), and vscode extension (`0.2.0`) to the current codev version.
Example
```
$ pnpm bump-version 3.0.0-rc.12
Bumped @cluesmith/codev → 3.0.0-rc.12
Bumped @cluesmith/codev-core → 3.0.0-rc.12
Bumped @cluesmith/codev-types → 3.0.0-rc.12
Bumped codev → 3.0.0-rc.12
```
All four `package.json` files update. Continue the release as usual. Verify:
```
$ tar -xzOf packages/codev/cluesmith-codev-3.0.0-rc.12.tgz package/package.json | grep codev-core
"@cluesmith/codev-core": "3.0.0-rc.12",
```
End users installing codev@3.0.0-rc.12 get codev-core@3.0.0-rc.12 — same source tree, no drift.
Out of scope
- Publish-ordering logic — release protocol step 7 already handles this via `pnpm publish --filter`.
- Types-on-npm decision — protocol already publishes types.
- Changesets / release-please / lerna — manual stays manual.
- `@cluesmith/codev-dashboard` — bundled into `dashboard-dist/`, not published; bump script skips it.
Full plan
Detailed implementation steps, file-by-file changes, and verification runbook in `codev/plans/release-version-unification.md` (to be committed alongside the implementing PR).
Problem
The release protocol's step 7 handles publish ordering (core/types before codev) and idempotency well, but relies on human judgment for "if you've changed `packages/core/src/**`, bump core's version before publishing". When that step is missed, the drift bug from 0602 recurs:
A smaller second bug: even when core is bumped, nothing forces `dist/` to be rebuilt before publish. Stale `dist/` can ship (documented in `codev/specs/0602-codev-core-exports-issue.md`).
Proposed fix
Two small changes, ~20 lines of work total:
Plus:
Example
```
$ pnpm bump-version 3.0.0-rc.12
Bumped @cluesmith/codev → 3.0.0-rc.12
Bumped @cluesmith/codev-core → 3.0.0-rc.12
Bumped @cluesmith/codev-types → 3.0.0-rc.12
Bumped codev → 3.0.0-rc.12
```
All four `package.json` files update. Continue the release as usual. Verify:
```
$ tar -xzOf packages/codev/cluesmith-codev-3.0.0-rc.12.tgz package/package.json | grep codev-core
"@cluesmith/codev-core": "3.0.0-rc.12",
```
End users installing codev@3.0.0-rc.12 get codev-core@3.0.0-rc.12 — same source tree, no drift.
Out of scope
Full plan
Detailed implementation steps, file-by-file changes, and verification runbook in `codev/plans/release-version-unification.md` (to be committed alongside the implementing PR).