diff --git a/RELEASE.md b/RELEASE.md index 1785da122..58b7fb48f 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -19,7 +19,7 @@ own: a `main` tag builds and publishes two distributions (`mcp` and | Line | Branch | Tag | GitHub release flags | | ---------------------------- | ------ | ------------------------- | ------------------------------------- | | Current stable | `main` | `v2.X.Y` | not a pre-release; becomes **Latest** | -| Maintenance (previous major) | `v1.x` | `v1.28.Z` | not a pre-release; **not** Latest | +| Maintenance (previous major) | `v1.x` | `v1.X.Y` | not a pre-release; **not** Latest | | Pre-releases | `main` | `v2.X.YaN` / `bN` / `rcN` | **Pre-release** ticked, never Latest | The `Development Status` classifier in both `pyproject.toml` files is @@ -75,7 +75,7 @@ before the tag. the replacement version, since yanking doesn't stop `==` pins from installing the broken version. -## Maintenance release from `v1.x` (`v1.28.Z`) +## Maintenance release from `v1.x` (`v1.X.Y`) Land the `[v1.x]`-prefixed backport PRs (and any README banner update, which is the README PyPI shows for that version), verify the branch tip green, then @@ -89,11 +89,11 @@ create the release the same way with two differences: - **It must not take "Latest" back from the 2.x line.** The UI ticks "Set as the latest release" by default for the newest non-pre-release; untick it, or pass `--latest=false`, and afterwards confirm `/releases/latest` still names - the newest v2 tag. If it slipped, `gh release edit v1.28.Z --latest=false` + the newest v2 tag. If it slipped, `gh release edit v1.X.Y --latest=false` fixes it — release metadata only, no re-cut. ```shell -gh release create v1.28.Z --title v1.28.Z --target --latest=false --notes-file +gh release create v1.X.Y --title v1.X.Y --target --latest=false --notes-file ``` When generating notes, set **Previous tag** to the previous `v1.*` release by diff --git a/SECURITY.md b/SECURITY.md index 8bcb1d402..5a6987512 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -4,15 +4,15 @@ Thank you for helping keep the Model Context Protocol and its ecosystem secure. ## Supported Versions -| Version | Line | Support | -| ------------------------------------ | ----------------------- | ---------------------------------------- | -| 2.x (newest release) | current stable (`main`) | bug fixes, security fixes, new features | -| 1.28.x (`v1.x` branch) | maintenance | critical bug fixes and security fixes | -| < 1.28, and all pre-release versions | unsupported | upgrade to the newest 1.28.x or to 2.x | +| Version | Line | Support | +| ---------------------------------------- | ----------------------- | ------------------------------------------- | +| 2.x (newest release) | current stable (`main`) | bug fixes, security fixes, new features | +| 1.x newest release (`v1.x` branch) | maintenance | critical bug fixes and security fixes | +| older 1.x releases, and all pre-releases | unsupported | upgrade to the newest 1.x release or to 2.x | Only the newest release of a supported line receives fixes, so reproduce against it before reporting. If your project depends on `mcp` and is not yet ready for -2.x, constrain to `mcp>=1.28,<2` and follow the +2.x, keep a `<2` upper bound on your `mcp` requirement and follow the [migration guide](https://py.sdk.modelcontextprotocol.io/migration/) when you migrate.