Conversation
The README and get-started docs pinned 2.0.0b1 and described v2 as a beta. Ahead of the 2.0.0rc1 tag they now pin 2.0.0rc1 and describe v2 as a release candidate, so the tagged commit's README (the PyPI long description) names the version being released. The What's new page's serverInfo `_meta` note also drops its reference to a 2.0.0b3 release that was never cut: that change first ships in 2.0.0rc1. No-Verification-Needed: doc-only pin flip
📚 Documentation preview
|
There was a problem hiding this comment.
1 issue found across 5 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="docs/get-started/real-host.md">
<violation number="1" location="docs/get-started/real-host.md:26">
P2: Running these commands from a directory containing a project can let `uv` update its lockfile. Show `--frozen` in every documented launch command, matching the repository’s `uv` policy and the generated Claude Desktop entry.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
|
||
| ```bash | ||
| uv run --with "mcp[cli]==2.0.0b1" mcp run /absolute/path/to/server.py | ||
| uv run --with "mcp[cli]==2.0.0rc1" mcp run /absolute/path/to/server.py |
There was a problem hiding this comment.
P2: Running these commands from a directory containing a project can let uv update its lockfile. Show --frozen in every documented launch command, matching the repository’s uv policy and the generated Claude Desktop entry.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At docs/get-started/real-host.md, line 26:
<comment>Running these commands from a directory containing a project can let `uv` update its lockfile. Show `--frozen` in every documented launch command, matching the repository’s `uv` policy and the generated Claude Desktop entry.</comment>
<file context>
@@ -23,15 +23,15 @@ That is the last line of Python on this page. From here down it is all host conf
```bash
-uv run --with "mcp[cli]==2.0.0b1" mcp run /absolute/path/to/server.py
+uv run --with "mcp[cli]==2.0.0rc1" mcp run /absolute/path/to/server.py
</file context>
</details>
There was a problem hiding this comment.
LGTM — a mechanical docs-only pin flip from 2.0.0b1 to 2.0.0rc1, matching the RELEASE.md pre-release step.
What was reviewed:
- All five files: every
2.0.0b1pin and "beta" wording is consistently updated to2.0.0rc1/ "release candidate"; a repo-wide grep confirms no stale2.0.0b1,2.0.0b3, or "in beta" references remain. - The whats-new.md "since 2.0.0b3" → "since 2.0.0rc1" correction for the serverInfo
_metachange matches the PR description's rationale (b3 was never cut). - A candidate concern that whats-new.md credits
client.listento 2.0.0b2 was investigated and ruled out (b2 is a real release).
Extended reasoning...
Overview
This PR touches only README.md and four docs pages (installation, real-host, index, whats-new). Every change is either a version-pin string flip (2.0.0b1 → 2.0.0rc1) or accompanying prose updating "beta" to "release candidate" / "pre-release". One substantive prose fix corrects a stale claim that the serverInfo _meta change shipped in 2.0.0b3 (a release that was never cut) to 2.0.0rc1, which the PR description explains.
Security risks
None. No code, configuration, dependency, or CI changes — purely documentation text. The install commands documented are the same shape as before with only the version string changed.
Level of scrutiny
Low. This is the same pin-flip pattern used for the previous 2.0.0b1 release step per RELEASE.md, is docs-only, and carries no runtime behavior. The main failure modes would be a missed stale pin or an inconsistent version reference; a repo-wide grep confirms no 2.0.0b1, 2.0.0b3, or lingering "in beta" phrasing remains, and the readme-snippets/docs-build CI checks cover formatting.
Other factors
The bug hunting system found no bugs. Its one candidate issue — that whats-new.md credits client.listen to a never-cut 2.0.0b2 — was examined and refuted by verifiers. The PR has no prior reviews or outstanding comments. The author notes it should merge last before the v2.0.0rc1 tag, which is a sequencing concern for the release manager, not a correctness issue in the diff.
The pre-release pin-flip for
v2.0.0rc1, following the RELEASE.md pre-release step: the README and get-started docs pinned2.0.0b1and described v2 as a beta; they now pin2.0.0rc1and describe it as a release candidate, so the tagged commit's README (the PyPI long description) names the version being released. This should merge last before thev2.0.0rc1tag.Motivation and Context
Same shape as the b1 pin flip. Also fixes a stale token: the What's new page said the serverInfo
_metachange shipped "since 2.0.0b3", a release that was never cut; that change first ships in this rc.How Has This Been Tested?
Docs-only.
git grep 2.0.0b1in README and docs is now empty; the readme-snippets and docs build checks run in CI.Breaking Changes
None.
Types of changes
Checklist
AI disclosure
AI assistance was used to make this change; I reviewed the result and take responsibility for it.
AI Disclaimer