Describe the maintenance line without hardcoding 1.28

[maxisbey]

SECURITY.md and RELEASE.md named the maintenance line as 1.28.x / v1.28.Z, which went stale the moment v1.29.0 was tagged.

Motivation and Context

Refer to "the newest 1.x release" and v1.X.Y so the policy text doesn't need an edit on every maintenance release. The pinning advice is simplified to the operative <2 upper bound (the >=1.28 floor was arbitrary).

How Has This Been Tested?

Wording only.

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

_{AI Disclaimer}

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[claude]

LGTM — a docs-only wording change that de-hardcodes the maintenance line version, exactly as described.

What was reviewed: the RELEASE.md table and gh release commands now use the v1.X.Y placeholder consistently with the existing v2.X.Y convention, and the SECURITY.md support table rewrite is accurate. Checked the rest of the repo for stale 1.28 references — the remaining ones are either unrelated (opentelemetry-api), historical snapshots in the migration guide, or still-valid for example mcp>=1.28,<2 illustrations, so nothing else needed updating in this PR.

Extended reasoning...

Overview

This PR touches only two documentation files, RELEASE.md and SECURITY.md. It replaces the hardcoded maintenance-line version (1.28.x / v1.28.Z) with the generic v1.X.Y placeholder and the phrase "1.x newest release", so the policy text no longer goes stale on each maintenance release. It also simplifies the pinning advice in SECURITY.md to the operative <2 upper bound.

Security risks

None. No code, configuration, or workflow files are changed — this is prose in two markdown policy documents. The SECURITY.md edit does not weaken the policy; it restates the same support tiers (newest 2.x supported, newest 1.x in maintenance, everything older unsupported) in version-agnostic language.

Level of scrutiny

Low. This is a wording-only documentation update with no behavioral impact. The main things worth verifying were internal consistency and accuracy: the v1.X.Y placeholder matches the v2.X.Y convention already used elsewhere in RELEASE.md, the gh release example commands remain syntactically coherent with the new placeholder, and the new support-table language preserves the previous policy's meaning. All hold.

Other factors

The bug hunting system found no bugs. Two candidate issues were raised and ruled out: (1) that >=1.28 pinning examples remain in README/docs — verified these are illustrative for example constraints that remain correct, not policy statements that go stale; (2) that the new table no longer explicitly lists published 0.x releases as unsupported — the new "all pre-releases" plus "older 1.x releases" wording, combined with the table listing exactly which lines ARE supported, preserves the same effective policy. No prior reviews or comments exist on the PR. The change is small, self-contained, and matches the repo's stated documentation conventions.