Conversation
Co-Authored-By: Claude <[email protected]> Claude-Session: https://claude.ai/code/session_0194GteaD7THWZEzQxB22P1k
|
|
||
| ### Repositories | ||
|
|
||
| - An Experimental or Beta repository MUST contain exactly one extension. A Stable repository MAY group related extensions in one area, as SEP-2133 allows, but an extension joins a grouped repository only when it becomes Stable. |
There was a problem hiding this comment.
Possible minor challenge for Tasks (once again) with this: modelcontextprotocol/agents-wg#29
I'm proposing basically splitting Tasks into a stabilized portion (to be merged into the core spec) and experimental portion, which will probably coexist in the same repo for a while - it's unclear if that's allowed under this. Should we temporarily have both an ext-tasks and an experimental-ext-tasks(-v2?) repo simultaneously for a period of time if we went with this?
There was a problem hiding this comment.
Yeah, I thought this might come up. We could instead have ext-tasks contain multiple extensions, and we e.g. have ext-tasks/tasksv2/experimental/spec.md alongside ext-tasks/tasks/beta/spec.md
There was a problem hiding this comment.
This is a good point. @pcarleton mentioned ext-auth might have similar things.
What about just subfolders within the repo and the repo is just ext-tasks?
ext-tasks/spec/stable/tasks.md
ext-tasks/spec/experimental/partial-results.md
ext-tasks/spec/beta/steering.md
(names made up...)
| | Stage | Repository | Protocol changes | Changes approved by | Entry | What implementers can expect | | ||
| | ---------------- | ------------------------------------------------------- | ----------------------------------------------------- | -------------------- | ------------------------------------- | ------------------------------------------------------- | | ||
| | **Experimental** | `experimental-ext-<name>` | Any change, at any time, without notice | Extension Maintainer | Any Maintainer creates the repository | Nothing. The design may change or disappear. | | ||
| | **Beta** | `beta-ext-<name>` | Any change, with breaking changes expected to be rare | Extension Maintainer | Extensions Track SEP | Real usage is welcome. Breaking changes are documented. | |
There was a problem hiding this comment.
@nbarbettini mentioned in a meeting that the 'Release Candidate' framing is useful for setting expectations around a protocol release. If we're still planning to use that approach for the core protocol releases, should we also use that term here for extensions?
There was a problem hiding this comment.
Hmm, open to it, but I feel that RC sets an expectation that it is very close and just in a staging area for final release with only minor bugfixes, whereas beta evokes more of a "we're trying this out, might change significantly as we get production experience".
RC to me would be, e.g. the extension is accepted into the core protocol or stable release and we're just weeks before setting it in stone and it's unlikely to change (but still possible).
| An **Extension Maintainer** is a maintainer of the extension's repository who is listed in that repository's `MAINTAINERS.md`, as `ext-tasks` already does. As SEP-2133 provides for repository maintainers, the Core Maintainers appoint Extension Maintainers, who are normally the | ||
| leads of the associated Working Group or Interest Group. Every extension MUST have at least one Extension Maintainer. | ||
|
|
||
| "Extension Maintainer approval" means a pull request approved by at least one Extension Maintainer who is not its author. Extension Maintainers SHOULD coordinate changes through the associated Working Group or Interest Group. |
There was a problem hiding this comment.
We already have guidelines around decision making in the groups, can we link to this for 'how to coordinate changes?' https://modelcontextprotocol.io/community/working-interest-groups#decision-making-process
|
|
||
| **Iteration.** After entry, Extension Maintainers approve changes without further Core Maintainer review. | ||
|
|
||
| - Extensions SHOULD prefer additive changes, such as new optional fields or capability flags, over breaking changes. |
This branch has not been deployed
4 participants
Proposes a maturity lifecycle for MCP extensions: Experimental, then Beta, then either Stable (as an extension) or promotion to the core specification.
The stage is shown in the repository name (
experimental-ext-<name>,beta-ext-<name>,ext-<name>) and decides which protocol changes are allowed, who approves them, and what stability implementers can expect.This updates the extension lifecycle in SEP-2133, replaces its "every breaking change needs a new identifier" rule, and answers the "feature maturity tiers" open question in SEP-2596.
It also extends the SEP-2484 conformance requirement to the SEPs that move an extension to Stable.
For reviewers: the Transition section classifies the existing extension repositories (
ext-appsandext-authStable;ext-skillsandext-tasksBeta;ext-server-cardBeta once SEP-2127 is accepted).That classification is a proposal for the Core Maintainers.
AI assistance: drafted with Claude Code (research of existing SEPs and extension repositories, and writing the text). Design decisions and review are by @pja-ant.
🤖 Generated with Claude Code