Skip to content

docs: reconcile the v1 policy wording and fix branch-pinned PR-template links #1813

Description

@cliffhall

Rewritten 2026-07-31. This issue was filed on 2026-07-27 against a predicted end-state that did not happen, and most of its original scope has since been done or invalidated — see What changed at the bottom. What remains is two small, real inconsistencies.

1. The v1 policy wording disagrees with itself

Three places say v1 takes security fixes only; three say security and bug fixes. Pick one and make them agree.

Location Current wording
CONTRIBUTORS.md:76 "it takes security fixes only"
AGENTS.md:126 "creating security fixes for in deprecated maintenance mode"
README.md "Repo status" "security and bug fixes only"
AGENTS.md:149 "v1 — work targeting v1/main (the deprecated line: security and bug fixes only)"
AGENTS.md:182 "The deprecated v1 line, security and bug fixes only, no active development"
AGENTS.md:187 "legacy inspector version, no new activity except security and bug fixes"

This matters more now than when it was first filed. The v1 PR backlog has been triaged and closed (#1819): 120 PRs closed under closed-v1-deprecated, 8 of those additionally closed-v1-security-declined, and 5 retained for a final 1.0.5#1732 (DNS-rebinding TOCTOU in safeProxyFetch), #1296 (redact env vars and headers from logs), #1161 (reject missing Origin), plus #1190 and #1189. The close note told 120 contributors that v1 is security-fixes-only. A contributor reading AGENTS.md and concluding bug fixes are welcome will file work we then decline.

Recommendation: "security fixes only" everywhere, matching what the close note actually said. If the intent is broader than that, the close note is the thing that's now wrong, and that's worth knowing.

2. Branch-pinned links in the PR template

.github/pull_request_template.md links to CONTRIBUTORS.md twice, both pinned to blob/main/:

  • line 20 — https://github.com/modelcontextprotocol/inspector/blob/main/CONTRIBUTORS.md
  • line 26 — [CONTRIBUTORS.md](../blob/main/CONTRIBUTORS.md)

main is now release-only, so these resolve against the last released tree rather than the working one, and they will break outright when CONTRIBUTORS.md is renamed to CONTRIBUTING.md (see #1821, step 4) until a milestone merge carries the new name to main. Make them relative, or repoint them at v2/main.

Fold this into the rename work if that lands first — this issue then covers only item 1.

Out of scope

Remaining v2/main mentions in code comments and docs/launcher-config-consolidation-plan.md are historical prose describing what a past build did, not instructions. Leave them.

What changed since this was filed

The original issue assumed the runbook would end with v2 as the default main, and v2 PRs targeting main directly. That is not the model that emerged. v2/main remained the develop branch and still takes every v2 PR; main became release-only, receiving milestone merges. Consequently:

Done (in #1866 / #1873):

  • AGENTS.md Base Branches — replaced with a three-branch role table (v2/main develop, main release, v1/main maintenance) including which branch each publishes to.
  • AGENTS.md Project Status and Direction — rewritten for the post-cutover state.
  • README.md Repo status callout — it asserted the inverse of reality ("The main branch is the legacy v1 implementation"); corrected.
  • CONTRIBUTORS.md version table — listed v2's base branch as main; corrected to v2/main.

Invalidated — do not do these:

  • README's "open PRs against v2/main" — that line is correct under the actual model.
  • Remove the manual close-and-move-to-Done step, since auto-close will fire — v2 PRs still target v2/main, a non-default branch, so closing keywords still do not auto-close. AGENTS.md is right as written and the manual step must stay.

Moot:

  • Decide whether v1.5/main still needs its "frozen, do not delete" note — no v1.5 text remains in AGENTS.md, and the remote branch no longer exists.

Metadata

Metadata

Assignees

Labels

v2Issues and PRs for v2

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions