Discovered while cutting v0.23.0. Filing so v0.24.0 does not re-derive the flow.
The drift
scripts/release.mjs encodes the pre-OIDC manual-publish flow and is now unusable:
- phase1 attempts a real npm publish of the SDK (fails on OTP; publishing is now owned by release-publish.yml via the tag)
- phase2 and tag require minutes-sdk@X.Y.Z to already be visible on the registry, which under trusted publishing only happens AFTER the tag exists (chicken-and-egg)
- tag also publishes minutes-mcp itself, contradicting docs/release/procedure.md's claim that it "has no registry credentials and does not publish packages"
- procedure.md references a phase1 --dry-run flag that the script does not implement
What actually works (the flow both 0.22.1 and 0.23.0 shipped with)
- bump-version.mjs X.Y.Z, regenerate llms.txt, push, CI green
- Manual pin commit: crates/mcp package.json minutes-sdk -> X.Y.Z plus lockfile entry with the registry tarball URL and the integrity of the locally packed SDK (npm pack is reproducible for identical content, so the OIDC-published tarball matches)
- Draft release targeting the pin commit
- Manual annotated tag on the pin commit, push tag -> the four workflows build artifacts and publish sdk -> mcp and core -> cli
- Publish draft, pack/upload .mcpb, deploy site, bump Homebrew tap
Known wart: the pin-window CI gap
Between the pin commit and the tag publish, the MCP Lockfile / MCP Server / CI Gate jobs fail on main AND on every PR merge ref (npm ci cannot resolve the not-yet-published SDK). Happened for both 0.22.1 and 0.23.0; confuses contributors whose PRs go red through no fault of theirs (#526 hit this). Options: teach the MCP jobs to fall back to a local SDK pack when the pinned version is absent from the registry, or tolerate the window and document it.
Fixes wanted
Discovered while cutting v0.23.0. Filing so v0.24.0 does not re-derive the flow.
The drift
scripts/release.mjs encodes the pre-OIDC manual-publish flow and is now unusable:
What actually works (the flow both 0.22.1 and 0.23.0 shipped with)
Known wart: the pin-window CI gap
Between the pin commit and the tag publish, the MCP Lockfile / MCP Server / CI Gate jobs fail on main AND on every PR merge ref (npm ci cannot resolve the not-yet-published SDK). Happened for both 0.22.1 and 0.23.0; confuses contributors whose PRs go red through no fault of theirs (#526 hit this). Options: teach the MCP jobs to fall back to a local SDK pack when the pinned version is absent from the registry, or tolerate the window and document it.
Fixes wanted