Repository navigation
SEP-3392: Extension Lifecycle - #3392
pja-ant wants to merge 4 commits into
Conversation
Sorry, something went wrong.
Co-Authored-By: Claude <noreply@anthropic.com> 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?
Sorry, something went wrong.
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
Sorry, something went wrong.
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...)
Sorry, something went wrong.
There was a problem hiding this comment.
updated to use directories
Sorry, something went wrong.
| | 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?
Sorry, something went wrong.
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).
Sorry, something went wrong.
| 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
Sorry, something went wrong.
|
|
||
| **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. |
Sorry, something went wrong.
One area can hold extensions at different stages at once, for example a stable Tasks extension beside experimental additions. Putting the stage in the repository name allowed only one stage per repository and renamed the repository at every stage change. The stage is now the directory specification/<stage>/<name> inside an ext-<area> repository. A stage change is a directory move that a Core Maintainer approves, and no repository is renamed. Extensions that are promoted to core or ended move to specification/archived/.
| beta/ | ||
| steering.md | ||
| stable/ | ||
| tasks/ |
There was a problem hiding this comment.
maybe a nit, but should it be "ext-tasks/tasks/specification"? It seems like this would be easier to navigate if there are multiple extensions
Sorry, something went wrong.
|
|
||
| Core Maintainers retain the ability to archive an Experimental extension, or an experimental repository, at any time. | ||
|
|
||
| ### Beta |
There was a problem hiding this comment.
Is it worth signaling in beta if something is intended to be stable track or core track?
Sorry, something went wrong.
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-apps and ext-auth Stable; ext-skills and ext-tasks Beta; ext-server-card Beta 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