CNCF 项目进入毕业阶段后如何建立版本兼容与维护窗口清单

CNCF 项目“毕业”不是一句可以替代版本承诺的宣传语。对采用方来说，更实用的做法是把项目阶段、版本兼容、维护者生命周期和升级窗口分开记录，再用一张清单决定“现在能不能纳入生产、下一次升级要留多少时间”。CNCF 的生命周期包含 Sandbox、Incubation、Graduated 和 Archived；Graduated 表示项目已经达到更成熟、可用于生产的阶段，但不等于所有版本永远兼容。

最稳妥的判断方式是：把 CNCF 毕业状态当作成熟度信号，把版本兼容和维护窗口当作你们自己的运营合同。

官方资料入口：https://github.com/cncf/toc/blob/main/process/README.md

先把“毕业”与“长期支持”拆开

CNCF 的项目阶段解决的是生态成熟度和尽调流程，不直接替项目声明一个统一的 LTS 年限。官方流程说明，Incubation 项目申请 Graduation 时会进入 Due Diligence；毕业模板会检查技术审查、治理审查、维护者生命周期、至少两家组织的维护者分布、公开路线图、贡献渠道和安全自评等证据。对采用方而言，这些内容回答的是“项目有没有可持续的组织基础”，而不是“我安装的某个小版本还能获得多久修复”。

把毕业尽调要求翻译成版本兼容清单

第一步是建一份“项目事实卡”，不要只保存 CNCF 项目页链接。至少记录当前阶段、仓库与文档入口、发布节奏、支持分支、依赖生命周期、API 或协议的稳定性说明，以及最近一次安全自评或技术审查的位置。若项目是规范或多实现项目，还要记录兼容实现数量、生产使用证据和一致性测试维护情况。

第二步是把版本关系写成矩阵。横轴放项目版本或稳定分支，纵轴放你们依赖的 Kubernetes、容器运行时、云厂商接口、客户端 SDK 和数据格式；单元格只使用“已验证、待验证、不支持、需迁移”四种状态。这样比“支持 Kubernetes”更有用，因为真正的风险通常出现在组合边界。

第三步是规定证据更新时间。发布新版本时更新兼容矩阵；维护者或治理文档变更时更新责任人；出现弃用或安全公告时，立即把对应分支标为待处理。没有证据的单元格不要填“兼容”，填“未知”，并让未知状态阻止关键生产升级。

维护窗口要写成可执行的责任表

维护窗口不是一个模糊的“尽快升级”。建议按发布事件拆成四个时间点：公告发现、内部验证、灰度部署和结束支持。每个时间点绑定责任人、验证环境和回滚条件。例如，项目发布包含 API 弃用时，平台团队负责确认影响面，业务团队负责跑关键场景，值班团队保留旧版本镜像和配置，直到灰度指标稳定。

清单中还应保留三类提醒：一是维护者离任、治理模型或通信渠道改变；二是依赖的上游版本进入 Archived 或停止安全修复；三是项目文档与实际发布行为不一致。CNCF 的 Guide Posts 明确只是实践指引，不是统一的晋级硬性要求，所以企业不能把“通过 CNCF 阶段评估”当作自己的上线检查替代品。

采用前的最小落地步骤

1. 建立项目事实卡，保存 CNCF 生命周期页、治理文档、发布说明和安全自评链接。
2. 用真实依赖组合填一轮兼容矩阵，未知项不得默认为通过。
3. 选择一个非关键环境执行升级，记录迁移动作、耗时和回滚结果。
4. 把公告、验证、灰度、结束支持四个节点写进值班或变更系统。
5. 每季度复核项目阶段、维护者、路线图、版本策略和内部责任人。

常见问题

CNCF Graduated 是否等于长期支持版本？

不等于。它是项目成熟度和生产准备度信号，具体版本支持周期仍要看项目自己的发布与维护政策。

兼容矩阵里没有证据时应该填什么？

填“未知”，并安排验证任务。未知比误标“已验证”更容易被纳入变更风险管理。

项目进入 Archived 后还能继续使用吗？

技术上可能仍能运行，但应把它视为高风险依赖，优先评估替代方案、分叉维护成本和数据迁移路径。

最后的判断很简单：毕业状态告诉你项目已经通过了一套生态成熟度考察，版本兼容清单则告诉你它能否安全地进入你们的具体生产组合。两者都记录，升级决策才不会只依赖一枚徽章。