From 0abd8791eeb2867836f40144bd1dca5ff16b5f91 Mon Sep 17 00:00:00 2001 From: Max Isbey <224885523+maxisbey@users.noreply.github.com> Date: Wed, 29 Jul 2026 13:34:46 +0000 Subject: [PATCH] Describe the maintenance line without hardcoding 1.28 SECURITY.md and RELEASE.md named the maintenance line as 1.28.x / v1.28.Z, which went stale as soon as v1.29.0 was tagged. Refer to "the newest 1.x release" and v1.X.Y instead so the policy text no longer needs an edit on every maintenance release, and simplify the pinning advice to the operative <2 upper bound. No-Verification-Needed: doc-only change --- RELEASE.md | 8 ++++---- SECURITY.md | 12 ++++++------ 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 1785da1225..58b7fb48f5 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 8bcb1d4028..5a69875124 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.