Describe the maintenance line without hardcoding 1.28 (#3212)

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.