SEP-3398：发布周期更新

社区译文；来源： MCP ccaf9102

摘要

本提案为 Model Context Protocol（MCP）建立可预测的发布周期。规范每六个月发布一次，通常安排在三月和九月的最后一个星期二。每次发布采用八个月周期：两个月用于规划，随后是明确的 Core Maintainer 评审窗口，并在发布前进行稳定化。相邻周期重叠两个月。

每份 SEP 由一个工作组或 Core Maintainer 小组发起。提案全年持续开发，所有 SEP 类型都使用排定的 Core Maintainer 评审窗口。与发布绑定的提案必须在软冻结前达到 Final 并合入。SDK 在提案获接受后开始实现。未完成的提案移至后续周期，发布日期不随之顺延。

每个周期由一名主发布经理和一名副发布经理协调；副发布经理在下一次发布中转任主发布经理。所提议的过渡方案把原定于 2026 年 12 月的发布目标移至 2027 年 3 月下旬，此后进入固定节奏。

动机

贡献者需要知道优先级何时确定、提案何时能获得决定，以及实现必须在何时准备就绪。Core Maintainer 的评审能力有限，而工作组和 SDK 维护者需要足够时间开发提案、测试实现，并在规范发布前消除歧义。

当前的 SEP 指引定义了发起、评审、接受和最终化，但没有把这些阶段连接到固定重复的发布日历。SDK 分级政策要求 Tier 1 在规范发布前提供支持，具体时间线按每次发布协商。明确的里程碑可以让这种协调变得可预测。

Core Maintainer 在 MCPCon Europe 最近一次 Core Maintainer Day 上确定了这套拟议流程。本 SEP 将该提案正式化。未完成的提案移至下一次发布。

规范

发布节奏概览

MCP 通常在三月和九月的最后一个星期二发布规范。发布经理在每个周期公布的日历中确认确切日期。每个周期从目标发布日期前八个自然月开始。前两个月专用于规划，最后两个月与下一次发布的规划期重叠。

所有发布里程碑都以距离发布的自然月数表示，包括半个月的间隔。这些偏移量确定规划目标；公布的发布日历给出确切日期和截止时间。

下方两个周期使用同一条月份时间轴。**一月下旬至三月下旬是两个月的重叠期：**三月版本正在稳定化，同时九月版本已开始规划。图示表达重复节奏；其中日期仅为示意，确切截止时间以公布的发布日历为准。

  ---
config:
    gantt:
        displayMode: compact
        leftPadding: 140
---
gantt
    title 八个月周期，发布间隔六个月
    dateFormat YYYY-MM-DD
    axisFormat %b
    tickInterval 1month
    todayMarker off

    section 三月发布
    规划       :march_plan, 2027-07-28, 2027-09-28
    CM 评审    :march_review, 2027-09-28, 2028-01-13
    稳定化     :march_stabilize, 2028-01-13, 2028-03-28

    section 九月发布
    规划       :september_plan, 2028-01-28, 2028-03-28
    CM 评审    :september_review, 2028-03-28, 2028-07-12
    稳定化     :september_stabilize, 2028-07-12, 2028-09-26

    section 发布
    三月       :milestone, march_release, 2028-03-28, 0d
    九月       :milestone, september_release, 2028-09-26, 0d

下一周期的规划在当前版本发布当天结束，其 CM 评审窗口也在当天开放。对于九月发布，同样的重叠期从七月下旬持续到九月下旬，其间下一年三月周期开始规划。SDK beta 和冻结时间见上方里程碑表。

发布管理

每次发布设一名主发布经理和一名副发布经理。发布经理须为自荐的 Maintainer，并由全部有投票资格的 Core Maintainer（CM）中超过半数投赞成票选出。投票资格遵循投票与结果记录。

Core Maintainer 为两名发布经理提供履行职责所需的访问权限，包括仓库、发布工具、评审队列和沟通渠道，并邀请两人参加所有 CM 会议。

一名经理在一个周期担任副经理，并在下一个周期担任主经理。CM 在下一次发布开始规划前选出新任副经理。

主发布经理对发布日历、评审安排、范围跟踪、冻结协调、SDK 就绪、发布和沟通负责。副发布经理参与这些工作，与主经理共同维护队列和交接记录，并学习发布程序。发布经理负责协调和上报决定；SEP 接受权和例外批准权仍归本 SEP 指定的角色所有。

如果一名经理无法继续履职，CM 通过同样的提名和投票流程选出替代者，并记录更新后的任命。

采用本流程完成首次发布后，发布经理须发布复盘，涵盖队列等待时间、软冻结时的就绪状态、SDK beta 可用性、紧急变更，以及重叠期内的经理工作量。对本流程的实质性修改遵循 SEP 工作流。

规划——发布前 8 个月

规划从发布前 8 个月开始，持续到发布前 6 个月 CM 评审窗口开放。规划开始时，发布经理公布该周期各里程碑的确切日期和截止时间。

规划期间，Core Maintainer 提出路线图，收集维护者和工作组（WG）的反馈，并发布覆盖未来六至十二个月的优先事项。规划识别 WG 和 SDK 之间的依赖。进入路线图表示获得评审优先级，但不保证提案会获接受或纳入某次特定发布。

CM SEP 评审——发布前 6 至 2.5 个月

CM 评审窗口在发布前六个月开放，并在软冻结时关闭。该窗口适用于 Standards Track、Extensions Track、Process 和 Informational SEP。排定的预评审和正式评审都在此窗口内进行。提案可以全年提交到队列。

WG 在整个周期中继续起草、制作原型、收集社区反馈并进行内部评审。面向后续版本的规范变更在当前版本发布前保留在提案分支或 PR 中。

Process 和 Informational SEP 可以在获接受并完成其实现要求后生效。扩展保留自身的发布生命周期；其 CM 评审时间遵循本 SEP，而规范冻结只约束正在准备的规范发布范围。

发起与提交

SEP 在正式评审前必须由一个工作组或 Core Maintainer 小组发起，并由一名指定代表代表发起小组。发起决定支持把提案送交评审；正式接受仍需要单独作出决定。

• **WG 发起：**在公开可读、由 WG 指定的仓库或 fork 中开发提案，并通过现有的 WG 决策流程获得批准。WG Lead 记录决定和未解决的关切，然后把准备就绪的 SEP 提交到 SEP 评审队列。
• **Core Maintainer 小组发起：**Core Maintainer 同意发起提案并指定一名 CM 代表小组。该代表记录发起决定，征询相关 WG，并把准备就绪的 SEP 提交到同一队列，无需另行取得 WG 批准。

两条路径在把提案提交队列接受正式评审前，都必须在 MCP 主仓库建立规范 SEP PR。按照 SEP-1850，在该 PR 分配 SEP 编号前使用占位编号。由 WG 发起的 PR 链接 WG 评审与批准；由 Core Maintainer 小组发起的提案可以直接在主仓库开始。PR 中须记录发起小组的决定，以及与受影响 WG 的协商情况。

SEP 的 Sponsor 字段填写代表发起小组行事、并负责状态、标签和实现跟踪的 Maintainer 或 Core Maintainer。符合资格的 WG Lead 可以担任该角色；由 Core Maintainer 小组发起时，则由指定 CM 担任。

两条路径使用相同的队列、评审安排和接受要求。某份 SEP 被选中讨论时，发布经理邀请 WG Lead 或指定 CM（视情况而定）及所有 SEP 作者参加 CM 会议。

评审队列与安排

发布经理维护公开的 SEP 评审队列。每个条目记录提案链接、发起小组及其代表、已指定时的 maintainer sponsor、申请的评审类型、就绪日期、与路线图的一致性，以及目标评审周期。正式评审条目链接规范的上游 SEP PR。预评审条目可以链接尚无上游 SEP 编号或尚未完成小组批准的初始提案。

WG Lead 或指定 CM 可以申请可选预评审，在投入完整提案前讨论方向、依赖和主要关切。预评审只提供指导，不授予接受状态，也不预留发布范围。

安排每次议程时，发布经理先处理准备就绪的正式评审，再处理预评审。每类内部先处理与路线图一致的提案，然后按就绪日期从早到晚排序。任何调度例外都须在队列中记录原因。因需要实质性修改而退回的提案，在重新提交时取得新的就绪日期；仅因议程时间不足而延期的就绪提案保留原就绪日期。

正式评审在评审窗口内的常规 Core Maintainer 会议上进行。每次正式评审遵循以下流程：

1. **会议前两周：**发布经理与 Core Maintainer 一起选择准备就绪的提案，并公布议程和提案链接。
2. **会议前一周：**评审者异步留下评论。作者和 sponsor 回复评论，并指出需要讨论的问题。
3. **会议期间：**作者、WG Lead 或指定 CM 介绍提案、剩余问题和已有实现反馈。
4. **介绍结束后：**开启下文规定的记录式投票，并在 SEP PR 和队列中公布结果及所需后续工作。

排定的投票必须在适用的软冻结或硬冻结前结束并通过。与发布绑定的 SEP 必须在软冻结前达到 Final 并合入，后续修正必须在硬冻结前合入。合入前须满足所有适用要求，包括一致性测试。硬冻结后的变更须获得紧急批准。进入队列既不保证获得评审时间，也不保证纳入发布。

投票与结果记录

介绍结束后，指定的 maintainer sponsor 在 maintainer Discord 服务器中发起一场有记录、持续七个自然日的投票，并从 SEP PR 链接投票记录。记录须标明被投票的提案修订版、投票截止时间和有资格的投票者：投票开始时在册的当前 Core Maintainer 小组，包括 Lead Maintainer，不包括 emeritus 成员。

接受提案需要全部有资格投票者中超过半数投赞成票。弃权和缺席不计为赞成，仅有参会者中的多数也不足以通过。超过半数投票拒绝则提案被拒绝；否则，未达到接受门槛的提案退回修改或留待后续评审。Sponsor 在 SEP PR 中记录票数、决定、理由和后续工作，并按现有指引更新状态。

除硬冻结规定的缩短紧急投票外，投票必须保持开放满七天。投票期间对提案作出实质性修改时，应把提案退回评审，不能用针对早期修订版投出的票接受修改后的提案。无法在评审窗口关闭前结束的投票推迟到下一窗口，部分结果不能算作接受。

投票结束时生效的规则适用，即使投票开始于冻结前。软冻结后只能处理冻结范围内的修正；硬冻结后，变更必须符合紧急条件和完整 CM 投票要求。获得批准不能免除变更合入时已经生效的冻结规则。

现有的 Lead Maintainer 权限继续有效。如果提案修改治理规则，则适用 SEP-2085中更严格的提案、意见征集期和批准要求。

接受后的实现

SEP 获接受后，SDK 维护者应尽快开始实现。早期实现和预发布版本应在仍可修改时，把歧义和互操作性发现反馈给作者、sponsor、相关 WG 和 Core Maintainer。

SEP 达到 Final 不以 SDK 实现为必要条件。

软冻结——发布前 2.5 个月

软冻结时，纳入规范发布的每份 SEP 都必须达到 Final，且其变更已经合入。这包括规范正文、适用的 schema 变更、变更日志条目、完成的参考实现，以及 SEP-2484要求的所有一致性测试。仅达到 Accepted 不满足截止条件。

发布经理公布冻结范围和延期提案。从软冻结到硬冻结期间，变更仅限冻结范围内的错误修复、完善和澄清。新功能和实质性重设计移至后续周期。修正性变更仍遵循正常评审和适用的测试要求。

已接受但未能完成最终化的提案保持 Accepted，并转入后续发布跟踪。仍等待决定的提案保留原状态并返回队列。仅因延期不需要重复接受投票，但实质性重设计需要重新评审。被拒绝的提案遵循现有拒绝和重新提交流程。

提案是否纳入后续周期仍取决于其就绪程度和该周期范围。发布日期不会为了未完成的提案而移动。

下一周期规划——发布前 2 个月

下一次发布的规划在当前版本发布前 2 个月开始，此时当前版本仍处于稳定化阶段。该时间点距离下一次发布 8 个月。下一周期沿用上述规划流程，在当前版本发布当天结束规划并开放 CM 评审窗口。

在两个月重叠期内，当前周期的副发布经理同时担任下一周期的主发布经理。其在协助当前版本稳定化的同时，与新任副经理一起领导下一周期规划。离任主发布经理继续对当前版本负责，直至完成发布。

SDK Beta——发布前 1.5 个月

Tier 1 SDK 在发布前 1.5 个月发布支持冻结规范范围的 beta 版本，使客户端和服务器开发者能在硬冻结前用半个月报告问题。Beta 发行说明须标明目标规范版本、可用功能、已知缺口和反馈渠道。SDK 维护者向发布经理提供一致性测试结果和未解决的阻塞项。

该里程碑覆盖 SDK 分级政策要求的功能；它不会强制 Tier 1 支持实验性功能或扩展。鼓励其他 SDK 参与 beta 里程碑，并继续履行其现有分级承诺。

发布经理维护公开的就绪摘要，其中列出 SDK 版本、一致性测试结果、缺口、负责人和预计解决日期。错过 beta 或稳定版里程碑的问题须上报 Core Maintainer 和 SDK WG，并在发布指引中披露。单个 SDK 延期不会推迟规范发布，也不会自动改变该 SDK 的级别；级别决定仍适用现有分级政策。

硬冻结——发布前 1 个月

硬冻结从发布前 1 个月开始。对冻结规范的任何变更都须通过完整 Core Maintainer 投票批准。只有用于处理严重安全漏洞，或阻塞发布的正确性或互操作性缺陷的变更，才有资格进入投票。新增功能和非必要的重设计不符合条件。

主发布经理通过正常 PR 工作流协调每个例外：

1. 确认拟议变更符合上述紧急条件。记录符合条件的缺陷、为何不能等待、所提议的最小修正，以及它对 SDK 和发布制品的影响。不符合条件的变更不得提交投票。
2. 主发布经理针对修正 PR 向完整 Core Maintainer 小组发起有记录的投票。不需要另建 SEP、指定 SEP sponsor 或进行会议介绍。
3. 合入前取得受影响实现维护者的评审，并运行相关回归和一致性检查。如果可观察的协议行为发生变化，须更新适用的一致性测试覆盖。
4. 记录投票、决定、验证结果和所有修改后的实现指引。通知受影响的 SDK 维护者，并更新就绪摘要和发行说明。

紧急投票可以在 CM 评审窗口之外举行和结束。主发布经理可以在必要时缩短七天投票期，但须把截止时间和原因通知所有有资格的 CM。批准仍需要全部有资格 CM 中超过半数投赞成票。投票资格和 Lead Maintainer 权限遵循投票与结果记录。

合入前必须完成批准和验证。如果缺陷无法及时安全修正，移除受影响的新功能及其依赖变更也必须构成符合条件的紧急事项，并通过相同的完整 CM 投票批准。其余规范按计划推进。

涉及安全敏感信息时，遵循现有安全报告与披露流程。在禁运期间，将决定和验证记录保存在受限渠道中，并在允许披露时发布。

发布——0 个月

Tier 1 SDK 按照现有功能支持承诺，在规范发布前提供稳定版支持。

发布当天，使用现有发布程序公布带日期的规范、发行说明、实现与迁移指引，以及 SDK 就绪摘要。协议版本继续使用日期格式。完成交接记录，列出未解决问题和后续负责人。新任主发布经理继续领导下一周期，其评审窗口也在当天开放。

过渡与采用

本 SEP 提议把原定于 2026 年 12 月的发布移至 2027 年 3 月 30 日，即三月的最后一个星期二，最终以过渡日历确认的日期为准。上一版规范发布于 2026 年 7 月 28 日。第一个周期使用 2026 年 8 月已经完成的规划。

本 SEP 获采用后两周内，Core Maintainer 按上述提名和投票流程选出首任主发布经理和副发布经理；两名经理随后公布过渡日历、评审会议以及确切的冻结、beta 和发布日期。首任主发布经理无需先在上一周期担任副经理。过渡日历在流程开始运行时开放首次评审窗口，并在按三月发布日期计算出的软冻结时关闭。只安排能够满足完整议程提前期和投票期的会议。

2027 年 9 月发布的规划从 2027 年 1 月下旬开始。2028 年 3 月发布的规划从 2027 年 7 月下旬开始。后续周期遵循完整的固定日历。

现有上游 SEP PR 继续有效，并保留其编号、讨论和已经作出的决定。在下一次正式评审前，提案须获得 WG 或 Core Maintainer 小组发起并进入队列；作者无需关闭 PR，也无需在 WG 仓库中重新创建 PR。已经接受的提案保留 Accepted 状态，但仍须满足发布就绪要求。本 SEP 本身按其获采用前生效的流程审议。

理由

日期可预测，范围可调整

六个月发布节奏为实现者提供固定的规划周期。八个月周期让路线图规划与稳定化重叠，使一个版本可以在准备下一版本优先事项的同时完成。用月数表达所有发布里程碑便于比较时间线，而公布的日历提供确切截止时间。

为了未完成提案而推迟发布，会让下一次发布更难规划。推迟范围而不是发布日期，可以给未完成工作新的机会，也不会把错过截止时间视为拒绝。

评审能力与发起机制

WG 评审在提案占用 CM 议程时间前引入领域反馈和原型。公开队列使优先级和延期决定可见。所有 SEP 类型使用同一个 CM 窗口可以简化安排，但也可能推迟在窗口外已经准备好的流程和扩展提案。持续的 WG 开发和可选预评审可帮助贡献者为下一次机会做好准备。

Core Maintainer 小组发起机制为流程变更、跨多个小组的提案，以及尚无既有 WG 的主题提供直接路径。征询相关 WG 保留领域反馈，而两种路径适用相同的评审和接受要求。指定 sponsor 继续负责状态和实现工作。

稳定化前就绪

要求 SEP 在软冻结前达到 Final 并合入，使 SDK 维护者获得可实现和测试的明确规范。让仅达到 Accepted 的设计进入稳定化，会使规范正文或一致性工作与错误修复争夺时间。提前实现 SDK 可以降低这种风险，同时不把每个 SDK 实现都设为 SEP 最终化的条件。

投票记录与紧急评审

七天投票期允许不同时区的成员参与，也给未出席会议者明确的投票机会。要求全部有资格成员中的多数赞成，可以避免少数参会者决定接受提案；代价是每个截止日期前都需要足够的参与度。

完整 Core Maintainer 投票确保对冻结发布范围的变更由整个小组负责。

轮换与过渡

先担任副发布经理可以为领导下一周期做好准备。明确每个重叠周期的负责人可避免交接模糊。把即将到来的发布目标移至 2027 年 3 月下旬，为引入日历和就绪里程碑留出时间，同时承认已经完成的规划工作。

向后兼容性

本 SEP 修改贡献和发布流程，不引入协议消息、schema 变更、版本协商变更，也不对已部署的客户端和服务器增加新要求。现有基于日期的规范版本继续有效。

由 WG 发起的提案增加小组批准阶段，而由 Core Maintainer 小组发起的提案可以直接提交到上游。两条路径都使用季节性的 CM 评审窗口。现有提案历史和接受决定按过渡程序保留。本 SEP 更新 SEP-1850 中有关发起和安排的部分，同时保留规范上游 PR、基于 PR 的编号、由 sponsor 管理状态，以及现有最终化要求。

SDK beta 和稳定版里程碑明确了发布预期，同时保留分级决定程序，以及实验性功能和扩展不属于强制级别覆盖的现有规则。达到 Final 的 SEP 继续作为历史记录保留；流程采用通过更新当前贡献者指引完成，而不会重写这些历史记录。

安全影响

本 SEP 不引入新的协议攻击面、身份验证行为或用户数据处理。固定日历仍须允许在冻结期内修复严重安全问题。紧急流程要求完整 Core Maintainer 投票、实现评审和相关验证，同时保留协调披露。公开队列条目和发行说明不得过早披露处于禁运期的漏洞细节。

参考实现

对于这份 Process SEP，实现由贡献者文档和运营设置组成。达到 Final 前需要完成以下工作：

1. 更新当前 SEP 指引和 WG 指引，说明发起、上游提交、评审安排、投票和过渡处理。
2. 发布发布周期文档和首份日历，包括确切 UTC 截止时间和评审会议。
3. 建立公开的 SEP 评审队列，发布 SDK 就绪摘要，指定其维护者，并记录首批发布经理任命。
4. 发布一份发布检查清单，涵盖冻结范围、紧急批准、SDK 里程碑、发布和交接。

相关文档变更、日历、队列和任命就绪后，在此处补充链接。Process SEP 不受协议一致性测试要求约束；现有发布工具可以继续用于发布。