MCP 社区
功能生命周期与弃用政策

功能生命周期与弃用政策

社区译文；来源： MCP 80041ab0

本政策定义 Model Context Protocol 规范中单项功能的生命周期，包括三种功能状态（Active、Deprecated、Removed）、状态转换的条件和程序、弃用到移除之间的最短窗口，以及每次转换所需的文档。

本政策通过 SEP-2596 采用。

范围

本政策适用于 MCP 核心规范的功能：协议消息、能力、传输、schema 类型和规范性行为要求。规范文档本身的修订生命周期（Draft、Current、Final）由版本控制指南 定义。

功能状态

规范功能在任一时刻恰好处于以下三种状态之一：

状态含义对实现者的预期
Active该功能属于 Current 规范修订版。按该功能的规范性要求实现。
Deprecated该功能仍在规范中，但已计划移除，并已记录迁移路径（见下文）。新实现不应采用该功能。现有实现应在最早移除日期前完成迁移。
Removed该功能已从 draft 删除，并将从下一个 Current 修订版中消失；它仍记录在最后一次包含该功能的 Final 修订版中。面向下一个 Current 修订版的实现不得依赖该功能。

Deprecated 功能 MAY（可以）通过一项取代原弃用 SEP 并记录情势变化的 SEP 恢复为 Active。恢复遵循与弃用相同的批准路径。如果该功能之后再次被弃用，弃用功能 中规定的最短弃用窗口，应从新弃用生效的修订版起重新计算。

SDK

从规范中移除功能，并不要求 SDK 在其发行版中删除该功能。该时间线由 SDK 自身的修订版支持政策管理。

弃用功能

出现以下情况时，可以提议弃用某项功能：

  • 已有另一项功能取代它并覆盖相同用例；
  • 它带来无法就地缓解的安全、隐私或互操作性风险；
  • 生态系统遥测或 SDK 维护者共识表明，相对于维护成本，其采用率可以忽略；
  • 或核心维护者认为适当的任何其他理由。

弃用属于规范变更，因此必须按 SEP 指南 提交 SEP。弃用 SEP 必须：

  1. 按名称标识该功能，并链接到 schema.ts 中的定义（如适用）和规范正文。
  2. 按上述条件说明理由。
  3. 记录迁移路径，或明确说明无需迁移。如果迁移路径指定了替代功能，该功能必须在弃用生效的修订版中处于 Active 状态；替代功能和弃用可以进入同一修订版。
  4. 指定最短弃用窗口：功能在具备移除资格前必须保持 Deprecated 的月数，且至少为十二个月。窗口从首次将该功能标记为 Deprecated 的规范修订版发布之日起计算，而不是从 SEP 达到 Final 状态之日起计算。窗口届满当日或之后首个作为 Current 发布的规范修订版中，该功能具备移除资格；该时间点即功能的最早移除时间。

弃用 SEP 被接受并达到 Final 状态后，弃用即进入计划。

  • 该功能在 schema.ts 中的条目会增加 @deprecated JSDoc 标签，引用弃用 SEP 和弃用生效的修订版。
  • 规范正文中的该功能会增加包含相同信息的弃用通知。
  • 该修订版的 changelog.mdx 会在“Deprecated”标题下增加一条记录。“Deprecated”和“Removed”与现有 Major/Minor/Other 分组并列，作为固定的变更日志标题。
  • 该功能会加入弃用注册表 ，并记录其弃用 SEP、成为 Deprecated 的修订版、迁移路径和最早移除时间。

当包含这些变更的修订版发布并成为新的 Current 修订版时，该功能转为 Deprecated（参见版本控制指南 ）。最短弃用窗口从该次发布起计算。

弃用注册表

docs/specification/draft/deprecated.mdx 是列出所有处于 Deprecated 或 Removed 状态功能的单一页面。它是“哪些功能正在退出，以及何时退出”这一问题的规范答案，使实现者无需从分散在各修订版变更日志中的弃用记录重建全貌。

Tier 1 SDK 的义务

某项功能成为 Deprecated 的修订版作为 Current 发布后，Tier 1 SDK：

  • 必须在下一发行版中使用相应语言的原生机制将对应 API 表面标记为弃用（例如 Java 的 @Deprecated、.NET 的 [Obsolete]、TypeScript 的 @deprecated JSDoc、Go 的 Deprecated: 文档约定），并在机制允许时引用弃用 SEP 和最早移除日期。
  • 应当在使用已弃用功能时，以该语言的惯用机制发出运行时警告（例如 Python 的 DeprecationWarning、Node.js 的 process.emitWarning 或可配置 logger）。

持续未能显式呈现 Deprecated 功能的 Tier 1 SDK，会进入 Tier 降级流程 。

移除功能

  1. 某项功能确定移除后，最短弃用窗口届满时，由核心维护者酌情执行移除。
  2. 移除必须记录在 changelog.mdx 和注册表 中。
  3. 对原弃用或移除 SEP 的任何变更都需要 SEP，例如延长或缩短时间线（加速移除 ），或将功能恢复为 Active（功能状态 ）。

功能可以保持 Deprecated 状态而不被移除，且持续时间可以远长于最短弃用窗口。

加速移除

如果某项功能带来现实存在的安全风险，即存在已发布安全公告的漏洞，或有已记录的真实攻击利用，且无法就地缓解，则可以缩短十二个月的下限。缩短窗口需要核心维护者依据治理决策流程 批准，并记录在弃用 SEP 中；如果风险在该 SEP 已达到 Final 后才出现，则记录在引用原 SEP 的简短加速移除 SEP 中。缩短后的窗口仍必须保证功能成为 Deprecated 到最早移除之间至少有九十天。

角色

操作执行者
提议弃用、延期或恢复任何贡献者，遵循 SEP 流程
担任发起人维护者或核心维护者，遵循 SEP 流程
批准弃用 SEP核心维护者，遵循治理决策流程
在发布准备期间决定移除核心维护者，遵循治理决策流程
批准延期或恢复 SEP核心维护者，遵循治理决策流程
批准加速移除核心维护者，遵循治理决策流程

根据治理角色 定义，Lead Maintainer 对上述每项批准均保留否决权。

工作组与兴趣组贡献者沟通