Promote the v2 README to README.md ahead of the first v2 beta (#3014)
This commit is contained in:
parent
f664db8952
commit
f2e63c979a
1 changed files with 84 additions and 2683 deletions
16
RELEASE.md
16
RELEASE.md
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue