--- title: "Versions and governance — MCP glossary" description: "How revisions are numbered, how features are retired, and how any of it changes." canonicalUrl: "https://zuplo.com/learn/mcp/glossary/governance" pageType: "mcp-glossary-group" --- # Versions and governance How revisions are numbered, how features are retired, and how any of it changes. One group of the [MCP glossary](/learn/mcp/glossary), which indexes every term A to Z. ## Protocol revision MCP versions are dates in `YYYY-MM-DD` form, naming the last date on which backward-incompatible changes were made. A revision is marked Draft, Current, or Final; the current revision is `2026-07-28`. The version is not incremented for backward-compatible changes. **Where you meet it.** Every revision keeps its own permanent documentation tree, so a search result can land you on guidance three revisions old with no warning on the page. Check the date in the URL before trusting anything you read about MCP. **Also written:** protocol revision, MCP version, 2026-07-28, protocol version, Draft Current Final **Source:** [MCP: Versioning](https://modelcontextprotocol.io/docs/2026-07-28/learn/versioning) **Read next:** [MCP-Protocol-Version](/learn/mcp/glossary/transport#mcp-protocol-version) · [Deprecated, Removed, and Active](/learn/mcp/glossary/governance#deprecated-vs-removed) · [SEP](/learn/mcp/glossary/governance#sep) ## Deprecated, Removed, and Active The feature lifecycle policy puts every specification feature in exactly one of three states. Active means implement it. Deprecated means it stays in the specification with a documented migration path, and new implementations should not adopt it. Removed means it has been deleted from the draft and will be absent from the next Current revision. **Where you meet it.** A Deprecated feature must stay put for at least twelve months from the revision that deprecated it — or ninety days under the security-driven expedited exception — before it is even eligible for removal, and it may stay far longer. No feature has yet reached the Removed state, which is why sessions and the `initialize` handshake are a separate case: `2026-07-28` deleted them outright as a breaking change rather than deprecating them first. **Also written:** deprecated, removed, feature lifecycle, deprecation policy, deprecated features registry, SEP-2596 **Source:** [MCP: Feature Lifecycle and Deprecation Policy](https://modelcontextprotocol.io/community/feature-lifecycle) · [MCP 2026-07-28: Deprecated features registry](https://modelcontextprotocol.io/specification/2026-07-28/deprecated) **Read next:** [DCR](/learn/mcp/glossary/credentials#dcr) · [Sampling](/learn/mcp/glossary/protocol#sampling) · [Roots](/learn/mcp/glossary/protocol#roots) · [HTTP+SSE transport](/learn/mcp/glossary/transport#http-sse) · [Mcp-Session-Id](/learn/mcp/glossary/transport#mcp-session-id) ## Official extension _Changed in 2026-07-28._ Tasks moved out of the core protocol into an extension in this revision (SEP-2663). Two sources differ on its standing: the extensions overview lists Tasks among the official extension repositories, while the `ext-tasks` repository README labels itself experimental and says it is not an official extension. An optional addition to the specification that defines capability beyond the core protocol, identified as `{vendor-prefix}/{extension-name}`. Official extensions use the `io.modelcontextprotocol` vendor prefix and live in `ext-`-prefixed repositories in the Model Context Protocol GitHub organization. There are four: `io.modelcontextprotocol/ui` (MCP Apps), `io.modelcontextprotocol/tasks` (Tasks), `io.modelcontextprotocol/oauth-client-credentials`, and `io.modelcontextprotocol/enterprise-managed-authorization`. **Where you meet it.** Both sides advertise support in the `extensions` field of their capabilities — clients inside `io.modelcontextprotocol/clientCapabilities`, servers in the `server/discover` response — and each extension defines its own settings object. Extensions are always off by default. If one side supports an extension and the other does not, the supporting side must fall back to core behavior or reject the request. **Also written:** official extensions, MCP extensions, io.modelcontextprotocol/ui, io.modelcontextprotocol/tasks, io.modelcontextprotocol/oauth-client-credentials, io.modelcontextprotocol/enterprise-managed-authorization, MCP Apps, extensions capability **Source:** [MCP: Extensions Overview](https://modelcontextprotocol.io/extensions/overview) · [MCP: Extension Support Matrix](https://modelcontextprotocol.io/extensions/client-matrix) **Read next:** [_meta](/learn/mcp/glossary/protocol#meta) · [server/discover](/learn/mcp/glossary/discovery#server-discover) · [SEP](/learn/mcp/glossary/governance#sep) ## Specification Enhancement Proposal (SEP) A SEP is a design document that describes a new feature for MCP or for its processes, and it is the mechanism required for any protocol change, breaking change, or governance change. SEPs are numbered by the pull request that introduces them and published in the specification repository. **Where you meet it.** Every change described on this page traces to one, which makes a SEP number the most precise citation available for an MCP claim. Statelessness is SEP-2567 and SEP-2575, MRTR is SEP-2322, the deprecation policy is SEP-2596, and the sampling and roots deprecations are SEP-2577. **Also written:** SEP, specification enhancement proposal, SEP-2575, SEP-2322 **Source:** [MCP: SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines) **Read next:** [Protocol revision](/learn/mcp/glossary/governance#protocol-revision) · [Deprecated, Removed, and Active](/learn/mcp/glossary/governance#deprecated-vs-removed)