Repository navigation
go-live 3/9: lock the v1 dist-tag and deprecate all four packages on npm #1816
Description
Activity
- changed the title
[-]go-live 2/9: v1 deprecation notice + publish 1.0.1 from v1/main (OIDC rehearsal)[/-][+]go-live 3/9: lock the v1 dist-tag and deprecate all four packages on npm[/+]on Jul 27, 2026 Phase 3 complete. Verified against the live registry:
Check Result publish-allpins--tag v1-latest✅ on v1/main(#1828, corrected by #1829)v1-latest→ 1.0.1✅ all four packages npm i …@v1-latestresolves✅ 1.0.1 npm deprecate @<2.0.0✅ all four; confirmed on 1.0.1, 1.0.0, and back through 0.x Warning on a real install ✅ all four, full message, in a clean throwaway consumer Two runbook errors found and fixed — both would have surfaced later and worse:
v1is not a legal dist-tag. npm rejects any tag parsing as a SemVer range. Beyond failingdist-tag add, the--tag v1merged in chore: pin v1 publishes to thev1dist-tag #1828 would have made the next v1 security release fail to publish at release time, mid-incident. Nowv1-latest(fix: v1 dist-tag must bev1-latest— npm rejectsv1#1829), with the workflow comment recording both failure modes so neither the flag nor the specific name gets "cleaned up" later.<=1.0.0for the sub-packages was stale — written before phase 2 shipped 1.0.1 to all three, so it would have left the versionlatestpoints at un-deprecated. Now<2.0.0everywhere.
Also worth recording: the deprecation message had to be applied from a script file, not a pasted command. A long pasted line gets hard-wrapped by the terminal and the embedded newline is stored verbatim — npm then truncates its warning at the break, hiding the upgrade pointer. Took two attempts to spot; the tell was the break moving with message length. Anyone re-running
npm deprecateshould build the string in a file.The
latest→ v1 trap (#1804 §1) is now closed ahead of 2.0.0.- added a commit that references this issue
on Jul 28, 2026
Phase 3 of 9 in the v2 go-live runbook — see #1804 (§1, §3). Depends on phase 2. Mostly reversible.
Close the two npm-side traps left open by the 1.0.1 publish.
Status: complete. See the corrections note below — the runbook's
v1tag name and<=1.0.0range were both wrong.Tasks
--tag v1-latestonv1/main'spublish-all(covers the root and, via--workspaces, the three sub-packages). chore: pin v1 publishes to thev1dist-tag #1828 + fix: v1 dist-tag must bev1-latest— npm rejectsv1#1829.v1-latest→ 1.0.1 on all four names, sonpm i @modelcontextprotocol/<pkg>@v1-latestresolves consistently and the deprecation message points somewhere real.npm deprecateall four names at@<2.0.0. Safe for the sub-packages — no 2.x will ever exist for them, since v2 ships only the root package.Why
--tag v1is the one to not forgetpublish-allhas no--tag, so npm assignslatestto whatever it publishes. Once 2.0.0 is out, a 1.0.2 security fix fromv1/mainwould movelatestback to 1.0.2 — everynpx @modelcontextprotocol/inspectorin the world silently reverts to deprecated v1. Nothing enforces this flag, and the cost of forgetting surfaces months later.The three sub-packages (
inspector-client,inspector-server,inspector-cli) are permanently orphaned at 1.0.0 with a livelatesttag — v2 publishes only the root package. Without deprecation, people keep installing packages that will never update again.npm deprecateis retroactive-but-mutable (liftable with an empty message), so it is the reversible step here.