Promote the v2 README to README.md ahead of the first v2 beta (#3014)

This commit is contained in:
Max 2026-06-29 13:01:54 +02:00 • committed by GitHub
commit f2e63c979a
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -33,11 +33,17 @@ the publish job — `skip-existing` makes it skip whatever already landed. The
`Development Status` classifier in both `pyproject.toml` files is permanently
`5 - Production/Stable`; it is not bumped as part of any release.
1. Check the full test matrix is green on the release commit. The matrix runs
1. Update the pre-release version examples in `README.md` and the docs
(grep the outgoing version — the pins live in the README Installation
section, `docs/index.md`, and `docs/installation.md`) so the tagged
commit — and therefore the README PyPI publishes — names the version
being released. When entering a new phase (alpha → beta → rc), update
the banner wording too.
2. Check the full test matrix is green on the release commit. The matrix runs
with `continue-on-error`, so a green workflow run does not mean the tests
passed — check the individual jobs.
2. Create the release as a pre-release, passing the exact commit verified in
step 1 as `--target` (otherwise the tag is created from whatever `main`'s
3. Create the release as a pre-release, passing the exact commit verified in
step 2 as `--target` (otherwise the tag is created from whatever `main`'s
HEAD is by then). The tagged commit determines everything about the
release — the workflows that run and the package metadata (readme,
classifiers) that gets published — so it must contain the current release
@ -50,13 +56,13 @@ the publish job — `skip-existing` makes it skip whatever already landed. The
gh release create v2.0.0aN --prerelease --title v2.0.0aN --target <commit-sha>
```
3. Curate the release notes instead of relying on auto-generated ones: what
4. Curate the release notes instead of relying on auto-generated ones: what
changed since the previous pre-release, what is known-incomplete, the
install line (`pip install mcp==2.0.0aN`), and a link to the migration
guide. Use the absolute URL
(`https://github.com/modelcontextprotocol/python-sdk/blob/main/docs/migration.md`)
because relative links don't resolve in GitHub release bodies.
4. If a pre-release turns out to be broken, yank it on PyPI and cut the next
5. If a pre-release turns out to be broken, yank it on PyPI and cut the next
one. Never delete a release from PyPI — version numbers cannot be reused.
Yanking doesn't stop `==` pins from installing the broken version, so set
the yank reason (and edit the GitHub release notes) to point at the