modelcontextprotocol/registry
Watch
1
0
Fork
You've already forked registry
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
registry/docs/contributing/releasing.md
Radoslav Dimitrov a25f166b4b
 docs: remove stale complete.md and fix remaining stale references (#1522) 
Deletes `complete.md` and cleans up the last references to the
pre-restructuring docs layout.

## Why `complete.md` goes

It is 2,944 lines (31% of all documentation lines in the repo)
self-described as *"all documentation from the docs/ directory compiled
into a single markdown file"*. But:

- **No generator exists.** No make target, no workflow, no script. `grep
-rn "complete\.md"` finds **zero** references anywhere in the repo.
- **It mirrors a docs tree that no longer exists** — `docs/guides/`,
`docs/explanations/`, `docs/concepts/`.
- **All 72 of its relative links are broken**, and six of the basenames
it references exist nowhere in the repo.
- **~14 current docs are missing from it entirely** (`about.mdx`,
`authentication.mdx`, `package-types.mdx`, both CHANGELOGs, ...).
- **Its `server.json` examples pin the superseded `2025-07-09` schema**
(current is `2025-12-11`).

The strongest argument is its own last commit. [PR
#1278](https://github.com/modelcontextprotocol/registry/pull/1278)
closed [issue
#767](https://github.com/modelcontextprotocol/registry/issues/767) — a
real user-reported CLI flag bug — by editing **only `complete.md`**. A
genuine fix landed in a file nobody reads, while the docs a reader would
actually find stayed wrong.

A generated file with no generator degrades into a trap: authoritative
enough that people edit it, with nothing validating it. If the
LLM-consumption use case is worth keeping, the right shape is a `make
docs-bundle` target plus a `check-docs-bundle` CI job mirroring the
existing `check-schema` pattern — happy to do that instead if you would
rather keep it.

## Remaining stale references

| File | Was | Now |
|---|---|---|
| `contributing/add-package-registry.md` | Add
`docs/guides/publishing/publish-[yourregistry].md`, update
`docs/guides/publishing/README.md` | Add a section to
`package-types.mdx`. These were the **last live references** to the
obsolete `docs/guides/` layout outside `complete.md` |
| `administration/maintainer-onboarding.md` | Add them to "Current key
maintainers" in README | "Registry Working Group" — the section that
actually exists |
| `reference/README.md` | Omitted 6 reference docs | Adds
`api/extensions.md`, `api/openapi.yaml`, `api/CHANGELOG.md`,
`server-json/CHANGELOG.md`, `server-json/CONTRIBUTING.md`,
`server-json/draft/` |
| `docs/README.md` | Index omitted `community-projects.md` | Listed |
| `reference/api/generic-registry-api.md` | `PUT .../versions/{version}`
"not implemented by official registry" | It **is** implemented
([edit.go:36](https://github.com/modelcontextprotocol/registry/blob/main/internal/api/handlers/v0/edit.go#L36)),
and `official-registry-api.md` already lists it as an admin endpoint |
| `reference/api/official-registry-api.md` | Omitted 3 registered routes
| Adds `POST /v0.1/validate` (which `mcp-publisher validate` calls),
`GET /v0.1/ping`, `GET /v0.1/version`, and notes these plus `/health`
are absent from `openapi.yaml` |
| `server-json/official-registry-requirements.md` | Per-registry
verification → `quickstart.mdx` | → `package-types.mdx`, which has an
Ownership Verification section per registry |
| `design/design-principles.md` | Sections 1,2,3,4,**6**,7 | Renumbered
1–6 |
| `contributing/releasing.md` | Steps 1,2,3,**5**,6 | Renumbered 1–5 |

I left the sibling `DELETE` claim in `generic-registry-api.md` alone —
it is accurate, no DELETE route is registered (the `http.MethodDelete`
hit in `server.go` is CORS config, not a route).

## Staleness banners rather than rewrites

**`design/tech-architecture.md`** is substantially fictional. Rather
than a vague "may be outdated", the banner lists what I verified is
wrong:

- Describes Helm-chart deployment; the registry is a plain `Deployment`
([registry.go:65](https://github.com/modelcontextprotocol/registry/blob/main/deploy/pkg/k8s/registry.go#L65)).
Helm is used only for third-party components.
- Diagram shows a `StatefulSet` on port **27017** — MongoDB's port. The
DB is PostgreSQL on 5432 via the CloudNativePG operator.
- Documents a `verify-domain` challenge flow (`POST /verify-domain`,
`/verify-domain/check`, server-issued tokens) that **was never built**.
- Documents `/admin/*` routes that are not registered.
- Says the DB stores user auth state and DNS verification records; only
`servers` and `server_extensions` tables exist.

**`design/roadmap.md`** still says "Phase 1: MVP/Go-Live (Current
Focus)" ~11 months after launch. I added a dated note rather than
inventing a current phase — that is a working-group call.

## Verification

All **101** remaining relative links across every `.md`/`.mdx` in the
repo resolve. The only two non-resolving matches are the intentional
`[project-name](link)` template placeholder and the moderation link
fixed in #1518.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 16:32:37 +03:00

2.7 KiB
Raw Permalink Blame History

Release Guide

Creating a Release

  1. Go to GitHub: Navigate to https://github.com/modelcontextprotocol/registry/releases
  2. Click "Draft a new release"
  3. Choose a tag: Click "Choose a tag" and type a new semantic version that follows the last one available (e.g., v1.0.0)
  4. Generate notes: Click "Generate release notes" to auto-populate the name and description
  5. Publish: Click "Publish release"

The release workflow will automatically:

  • Build binaries for 6 platforms (Linux, macOS, Windows × amd64, arm64)
  • Create and push Docker images with :latest and :X.Y.Z tags (note: no 'v' prefix)
  • Attach all artifacts to the GitHub release
  • Generate checksums and signatures

After Release

  • Docker images will be available at:
    • ghcr.io/modelcontextprotocol/registry:latest - Latest stable release
    • ghcr.io/modelcontextprotocol/registry:X.Y.Z - Specific release version (note: no 'v' prefix)
  • Binaries can be downloaded from the GitHub release page

Deploying to Production

Releases do not automatically deploy to production. To deploy a release:

  1. Update mcp-registry:imageTag in deploy/Pulumi.gcpProd.yaml to the desired version (e.g., 1.2.3 - note: no 'v' prefix)
  2. Commit and push the change to the main branch (either through a PR or by pushing directly to main)
  3. The deploy-production.yml workflow will automatically trigger and deploy the specified version

See the deployment documentation for more details.

Staging

Staging auto-deploys from main via deploy-staging.yml. It always runs the latest main branch code.

Rollback

To rollback production, update deploy/Pulumi.gcpProd.yaml to the previous version and push.

Note: Rollbacks may not work as expected if the release included database migrations, since migrations are not automatically reversed.

Docker Image Tags

The registry publishes different Docker image tags for different use cases:

  • :latest - Latest stable release (updated only on releases)
  • :X.Y.Z - Specific release versions (e.g., :1.0.0 - note: no 'v' prefix)
  • :main - Rolling tag updated on every push to main branch (continuous deployment)
  • :main-YYYYMMDD-sha - Specific development builds from main branch

Note: Git release tags include the 'v' prefix (e.g., v1.0.0), but Docker image tags follow the standard Docker convention and do not include the 'v' prefix (e.g., 1.0.0).

Versioning

We use semantic versioning (SemVer):

  • v1.0.0 - Major release with breaking changes
  • v1.1.0 - Minor release with new features
  • v1.0.1 - Patch release with bug fixes