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

Author: maxisbey

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 <commit-sha> --latest=false --notes-file <notes.md>
+gh release create v1.X.Y --title v1.X.Y --target <commit-sha> --latest=false --notes-file <notes.md>
 ```
 
 When generating notes, set **Previous tag** to the previous `v1.*` release by

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.