3. 版本发布策略
在 Containerd 运行时版本迁移与发布流水线适配中，版本发布策略是衔接上游社区演进与下游生产稳定性的核心契约。本章围绕语义化版本规范、稳定版与预览版区别、发布周期与节奏、版本兼容性矩阵四个维度展开，为流水线设计提供可量化的决策依据。
3.1 语义化版本规范
Containerd 严格遵循 语义化版本 2.0.0（SemVer），版本号格式为 MAJOR.MINOR.PATCH。每个字段的变更含义如下：
| 字段 | 示例 | 变更含义 | 流水线影响 |
|---|---|---|---|
| MAJOR | 2.0.0 → 3.0.0 | 不兼容的 API 或行为变更 | 需全量回归测试，更新客户端 SDK 与配置 |
| MINOR | 1.6.0 → 1.7.0 | 向下兼容的功能新增 | 可选升级，建议灰度验证新特性 |
| PATCH | 1.6.9 → 1.6.10 | 向下兼容的缺陷修复 | 推荐立即升级，低风险 |
实践提示： 流水线中应解析
version 字段并自动判断变更等级。MAJOR 变更触发人工审批门禁，MINOR 变更触发自动集成测试，PATCH 变更可直接进入快速发布通道。
此外，Containerd 在预发布版本中使用 预发布标签（如 -rc.1、-alpha.1）和 构建元数据（如 +build.20250301）。预发布标签的优先级低于正式版本，且不保证 API 稳定性。
3.2 稳定版与预览版区别
Containerd 社区同时维护两类发布通道，流水线需根据目标环境选择对应的制品源：
| 特性 | 稳定版（Stable） | 预览版（Preview） |
|---|---|---|
| 版本标签 | v1.6.9, v1.7.0 |
v1.7.0-rc.1, v2.0.0-alpha.1 |
| API 稳定性 | 完全向后兼容 | 可能变更，不保证兼容 |
| 缺陷修复 | 仅合入 PATCH 级修复 | 可合入功能与修复 |
| 推荐场景 | 生产环境、预发布环境 | 开发环境、功能验证、CI 先行测试 |
| 流水线门禁 | 需通过全量安全扫描与性能基线 | 通过冒烟测试即可 |
避坑提醒： 预览版（尤其是 alpha 版本）可能包含未完成的特性或已知的未修复缺陷。流水线中应使用独立的制品仓库隔离预览版与稳定版，避免误将预览版推送到生产环境。
3.3 发布周期与节奏
Containerd 社区采用 时间驱动 + 特性驱动 的混合发布模型。当前主流分支的发布节奏如下：
- LTS 分支（如 release/1.6）： 约每 2~3 个月发布一个 PATCH 版本，生命周期约 12~18 个月。
- 当前稳定分支（如 release/1.7）： 约每 4~6 周发布一个 MINOR 版本，包含新特性与修复。
- 主分支（main）： 每日构建，不发布正式版本，仅用于 CI 验证。
- 候选发布（RC）： 在正式版本发布前 1~2 周，通常发布 1~3 个 RC 版本。
流水线适配要点： 建议在流水线中配置版本订阅策略——LTS 分支订阅 PATCH 更新，稳定分支订阅 MINOR 更新，主分支仅用于开发环境自动部署。通过正则表达式匹配版本标签，自动路由到不同的发布管道。
3.4 版本兼容性矩阵
版本迁移的核心风险在于组件间的兼容性断裂。以下矩阵总结了 Containerd 与常见上下游组件的兼容关系，流水线应据此配置版本约束：
| Containerd 版本 | Kubernetes (kubelet) | runc | CNI 插件 | CRI-O (可选) |
|---|---|---|---|---|
| 1.6.x (LTS) | 1.23 ~ 1.28 | ≥ 1.1.0 | ≥ 1.1.0 | 不推荐混用 |
| 1.7.x | 1.24 ~ 1.30 | ≥ 1.1.4 | ≥ 1.2.0 | 不推荐混用 |
| 2.0.x (预览) | ≥ 1.28 | ≥ 1.2.0 | ≥ 1.3.0 | 不推荐混用 |
流水线校验建议： 在制品发布前，流水线应自动读取
go.mod 或 vendor.conf 中的依赖版本，与兼容性矩阵进行交叉比对。若发现不兼容组合，应阻断发布并生成差异报告。
3.5 版本迁移决策流程
综合上述策略，流水线中应内置以下版本迁移决策逻辑：
- 版本解析： 从制品仓库获取目标版本号，解析 MAJOR.MINOR.PATCH 及预发布标签。
- 兼容性检查： 查询版本兼容性矩阵，确认目标版本与当前集群中所有组件的版本约束。
- 变更等级判定： 根据语义化版本规范判定变更等级（MAJOR / MINOR / PATCH）。
- 门禁匹配： 根据变更等级触发对应的测试套件与审批流程。
- 灰度发布： 对于 MINOR 及以上变更，先部署到开发/测试环境，验证通过后再推送到预发布与生产。
自动化示例： 以下代码片段展示如何在流水线中解析版本并判定变更等级（伪代码）：
version = "v1.7.0-rc.1"
major, minor, patch, pre = parse_semver(version)
if pre:
pipeline.set_gate("preview_only")
elif major > current_major:
pipeline.set_gate("manual_approval + full_regression")
elif minor > current_minor:
pipeline.set_gate("integration_test + canary")
else:
pipeline.set_gate("fast_track")通过将语义化版本规范、稳定版/预览版区分、发布周期与兼容性矩阵固化为流水线规则，团队可以在保证安全性的前提下，实现 Containerd 运行时的自动化、可追溯版本迁移。