Describe the maintenance line without hardcoding 1.28 - #3212
Conversation
Sorry, something went wrong.
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
There was a problem hiding this comment.
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.
Sorry, something went wrong.
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
Checklist
AI Disclaimer