PR #2831 - modelcontextprotocol/python-sdk

Prepares the repo to publish v2 pre-releases (2.0.0aN) from main.

Motivation and Context

We want to start publishing v2 alphas to PyPI to get the rework into testers' hands. PEP 440 pre-release semantics keep 2.0.0aN invisible to anyone on mcp>=1.x (installers only select pre-releases on explicit opt-in), but some repo machinery assumes a single release line, and the published metadata would have been wrong:

pyproject.toml pointed PyPI's long description at the frozen v1 README.md, so a pre-release's PyPI page would have shown v1 docs. It now uses README.v2.md, with a refreshed banner (alpha status, opt-in install lines, v1.x recommendation, no committed GA date), absolute URLs (PyPI doesn't resolve relative links), and no GitHub-only [!IMPORTANT] alert syntax (PyPI's renderer shows it as literal text).
comment-on-release.yml picked the "previous release" by list order, which breaks once two release lines publish interleaved: v2.0.0a1's previous release would have been v1.27.2 — a cross-branch compare spanning all of main since the v1.25.0 branch point — and the next v1.x release would then have compared against v2.0.0a1. It now walks back to the nearest release whose tag is an ancestor of the current tag on the same major line, paginates the commit range instead of truncating at one response, tolerates candidates whose tag no longer resolves, accepts a release re-cut on the same commit, and labels comments on pre-releases as "pre-release". The first release of a new major line has no same-line predecessor, so it intentionally skips commenting rather than commenting on every PR in the new line's history.
RELEASE.md documents the pre-release flow: verify the matrix on the release commit, gh release create vX --prerelease --target <sha>, curated notes, and yank-don't-delete for broken pre-releases.
SECURITY.md states the pre-release policy: fixes land only in the newest pre-release; production stays on stable.
Classifier bumped to Development Status :: 3 - Alpha.

How Has This Been Tested?

Extracted the exact github-script bodies from the workflow YAML and executed them under node against the real GitHub API with simulated release lists. 12 scenarios pass, including: v1.27.2 → v1.27.1 (regression), simulated v2.0.0a1 → no comments (first of its major line), the next v1.x release skipping the diverged alpha and picking v1.27.2, incremental alpha-to-alpha selection, a release re-cut on the same commit, a different-major ancestor being skipped rather than aborting the walk, non-version tags, a candidate tag that 404s, and a 230-commit synthetic range collected across 3 pages.
Built the sdist and inspected PKG-INFO: the description is README.v2.md (text/markdown), the classifier is 3 - Alpha, and no relative links remain.
Verified compare-API commit pagination live on a 276-commit range.
pre-commit (prettier, markdownlint, uv-lock check, readme snippets) passes on all changed files.

Breaking Changes

None for users of the package. The PyPI long description for future uploads from main switches from the v1 README to the v2 README; v1.x releases are unaffected (the v1.x branch has its own pyproject.toml).

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

Additional context

This intentionally does not touch shared.yml's continue-on-error: true on the test matrix — which currently means failing tests block neither all-green nor publishing — beyond RELEASE.md telling the release manager to check the individual matrix jobs. Tightening that gate is a candidate follow-up.

_{AI Disclaimer}