v2 release pipeline, Phase 2: semver via changesets (TS), GitHub-Release-triggered publishing

[olaservo]

Description

Implements Phase 2 of the release-pipeline rebuild (#4472): semver via changesets for the TypeScript servers, CalVer retained for Python, and publishing triggered by manually-created GitHub Releases instead of workflow_dispatch.

What's in this PR

• One-time version reset: all four TS servers → 1.0.0 (everything comes down from its never-published staged 2.0.0). Hardcoded MCP serverInfo versions in the four index.ts files are aligned to 1.0.0 as well (they had drifted: 0.2.0/0.6.3/2.0.0).
• Changesets adoption: @changesets/cli + @changesets/changelog-github at the workspace root, .changeset/config.json, a new version-packages.yml workflow that maintains the rolling "Version Packages" PR on every push to main, and CONTRIBUTING/.changeset/README docs covering when a changeset is needed and the semver policy.
• release.yml rework: release: [published] trigger, all-packages matrix, and a registry-diff guard that skips (not fails) an already-published version and treats a never-published package (npm E404) as "publish it". No job computes, stamps, or tags a version. Test gates stay as defense in depth. The release environment and workflow filename are unchanged, preserving the OIDC trusted-publisher bindings on both registries.
• prepare-python-release.yml (workflow_dispatch): stamps today's CalVer date onto Python packages changed since their last version bump (refreshing uv.lock) and opens a normal PR. scripts/release.py is replaced by the focused scripts/prepare_python_release.py; the rest of it (version computation, matrix/notes generation) retires with the old flow.
• RELEASING.md rewritten to describe the merged state.

How this was tested

• changeset version run locally against a throwaway changeset: correctly bumped the target workspace package and generated a GitHub-flavored CHANGELOG (artifacts reverted).
• scripts/prepare_python_release.py run locally: correctly detected that all three Python packages have changes since their last version bump on main and stamped them to 2026.8.1 with uv.lock refresh (reverted — the real stamp happens via the dispatch after merge).
• The npm registry-diff guard logic from release.yml was run verbatim against the live registry: all four packages at unpublished 1.0.0 → publish; published semver (server-memory@0.6.2) and CalVer (server-everything@2025.4.8) versions → skip; a never-published package name (E404) → publish; jq normalization verified for both the bare-string (single published version) and array shapes of npm view versions --json.
• All four TS workspaces build at 1.0.0; root package-lock.json refreshed; workflow YAML parse-validated. No tests assert the old version strings.

Not in this PR (out-of-repo follow-ups)

• npm deprecate the CalVer ranges (>=2025.0.0 <2027.0.0) on the four TS packages with a pointer to the resumed semver line
• Install the changeset-bot GitHub App so PRs missing a changeset get flagged
• Verify PyPI trusted-publisher registrations (mcp-server-fetch, mcp-server-git, mcp-server-time) are bound to release.yml
• Optional: reusable workflow_call test definitions to prevent CI/release drift

Notes for reviewers

• PRs opened by version-packages.yml and prepare-python-release.yml use GITHUB_TOKEN, so they don't trigger CI — close/reopen runs it. This is documented in RELEASING.md. If we want CI to run automatically on those PRs, a GitHub App token or PAT would be needed (out of scope here).
• The Python packages' pyproject.toml versions on main still read 0.6.x because the old flow only pushed version bumps as tags, never back to main. The first prepare-release dispatch after this merges will stamp all three to the current date, which is correct — main becomes the source of truth from then on.

Types of changes

• New feature (non-breaking change which adds functionality)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• My code follows the repository's style guidelines
• New and existing tests pass locally

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the monorepo’s release pipeline to use Changesets-managed semver for the TypeScript servers, retain CalVer for Python servers, and publish packages from release.yml when a maintainer publishes a GitHub Release.

Changes:

• Reset TS workspace package versions (and MCP serverInfo versions) to 1.0.0 across the four TypeScript servers.
• Add Changesets tooling/config/docs and a rolling “Version Packages” PR workflow for semver bumps and CHANGELOG generation.
• Rework publishing to be GitHub-Release-triggered, with idempotent “registry-diff” guards and a new Python CalVer “prepare release” stamping workflow/script.

Reviewed changes

Copilot reviewed 18 out of 19 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/sequentialthinking/package.json	Reset TS package version to 1.0.0.
src/sequentialthinking/index.ts	Align MCP server version to 1.0.0.
src/memory/package.json	Reset TS package version to 1.0.0.
src/memory/index.ts	Align MCP server version to 1.0.0.
src/filesystem/package.json	Reset TS package version to 1.0.0.
src/filesystem/index.ts	Align MCP server version to 1.0.0.
src/everything/server/index.ts	Align server metadata version to 1.0.0.
src/everything/package.json	Reset TS package version to 1.0.0.
scripts/release.py	Remove old release-time version stamping/notes/matrix script.
scripts/prepare_python_release.py	Add Python CalVer stamping script that refreshes uv.lock.
RELEASING.md	Rewrite docs to describe the new versioning + GitHub-Release-triggered publish flow.
package.json	Add Changesets CLI scripts and devDependencies.
package-lock.json	Lockfile updates for Changesets dependencies.
CONTRIBUTING.md	Document when/how to add a changeset for TS servers.
.github/workflows/version-packages.yml	Add rolling “Version Packages” PR maintenance workflow.
.github/workflows/release.yml	Trigger on GitHub Release publish; publish per-package with registry guards.
.github/workflows/prepare-release.yml	Add workflow_dispatch Python CalVer stamping PR workflow.
.changeset/README.md	Add repo-local Changesets usage guidance.
.changeset/config.json	Add Changesets configuration (GitHub changelog integration).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 18 out of 19 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

.github/workflows/release.yml:76

• The npm registry guard redirects npm view stderr to /dev/null, so non-E404 failures can lose their most useful diagnostics (network/auth errors often go to stderr), leaving the logs with little/no actionable output. Capturing stderr separately keeps the JSON payload clean for jq while preserving troubleshooting info.

          # stdout only: with --json, npm writes errors as JSON to stdout, and
          # stray stderr warnings must not corrupt the payload we parse
          set +e
          PUBLISHED=$(npm view "$NAME" versions --json 2>/dev/null)
          EXIT_CODE=$?

[Copilot]

Pull request overview

Copilot reviewed 18 out of 19 changed files in this pull request and generated no new comments.

[cliffhall]

Is prepare-release.yml the best name for this, since it specifically is for python files? maybe prepare-python-release.yml

[olaservo]

Agreed — renamed to prepare-python-release.yml (matching its display name and scripts/prepare_python_release.py), RELEASING.md links updated. Unlike release.yml, nothing binds to this filename, so the rename is free.

🦉 — Claude, via Claude Code

[cliffhall]

LGTM! 👍