Docker 发布流程详解：基于时间周期的 9 周发布节奏、冻结期与 RC 机制（docker-ce 仓库视角）

• 容器运行时
• 云原生

本文以 RELEASE-PROCESS.md 为骨架，系统讲解 Docker 项目的发布全流程：从 9 周时间制发布周期的划分、第 7 周起的代码冻结与 RC 候选版本机制，到发布执行与推迟例外；并结合本仓库的project/目录（分支标签规范、补丁发布流程）与顶层构建产物（components.conf、Makefile、hack/make.sh）进行源码级佐证。读完本文，你将理解 Docker 社区是如何在“持续开发”与“稳定发布”之间取得平衡，以及作为贡献者如何在冻结日之前最大化自己的 PR 被合入下一版本的概率。

适用范围：一条发布流水线，牵动多个组件

RELEASE-PROCESS.md 明确说明，该发布流程并非只针对某一个二进制，而是覆盖 Docker 项目族中的全部核心组件，包括：

• Engine（容器运行时守护进程，即dockerd）
• Compose（多容器编排工具）
• Kitematic（桌面 GUI 客户端）
• Machine（主机初始化工具）
• Swarm（集群编排）
• Distribution（镜像仓库分发）
• Notary（镜像签名）
• 以及它们背后的基础依赖库，例如libnetwork、libkv等

在本仓库（docker-ce）的布局中，这种“多组件协同发布”的形态可以直接看到对应物：仓库根目录的 components.conf 声明了三个子组件——packaging、engine、cli，分别来自各自的上游仓库，而顶层 Makefile 则为它们提供统一的deb、rpm、static打包入口。也就是说，RELEASE-PROCESS.md描述的“多个项目在同一天一起发布”的模式，落到 docker-ce 这个聚合仓库里，就体现为一次构建同时产出 CLI、Engine 与各发行版安装包。

另外需要说明：原文档引用的RELEASE-CHECKLIST.md（逐步骤技术清单）在外部上游仓库中维护，本仓库快照的components/engine/project/目录并不包含该文件；project/README.md 中也仅是对应地指向它。因此本文以发布流程的主体机制为准展开。

发布周期：9 周一次的时间制（time-based）发布

Docker 项目采用时间制发布周期，而不是“功能攒够了才发”的功能制。核心约定有两条：

1. 每 9 周发布一次；
2. 一个发布周期结束的当天，就是下一个发布周期开始的日子，前后周期无缝衔接，不存在空档期。

这种固定节奏带来的直接好处是：外部用户、发行版打包者、下游企业都可以据此规划升级与适配窗口，而不是被动等待某个功能完成。原文档用一句话概括了这一机制——“A release cycle starts the same day the previous release cycle ends”，即上一轮发布即是下一轮开发的起点。

前 6 周：开发与评审阶段

周期的前 6 周专门用于开发与评审：

• 提交到任何一个子项目（Engine、Compose 等）的新特性与 bug 修复，都有资格进入下一个版本；
• 但没有任何变更集被保证能合入当前发布周期——eligible（有资格）与guaranteed（被保证）是两回事，这一点在下文“最大化合并概率”一节还会反复强调。

后 3 周：冻结期与 RC

第 6 周结束时，代码库被正式冻结，状态接近最终发布形态，同时创建一个Release Candidate（RC）候选版本。从仓库本身的版本号演进也能看到 RC 的实际形态：仓库根目录的 VERSION 文件当前记录为20.10.0-beta1，而分支标签规范中明确 RC 应打为vX.Y.Z-rcN（详见下文“分支与标签规范”小节）。

冻结期的定位是“找 bug、收集反馈”，其核心机制如下：

• master分支不冻结，继续正常的日常开发节奏；
• 但不再接受任何新特性进入 RC；
• master上修复的 bug，由release owner（发布负责人）有选择性地 cherry-pick（挑选移植）到 RC 分支中，只挑“关键”的；
• 每当 RC 内容发生变化，就会放出新的 RC 版本供社区测试与评审。

换句话说，冻结期不是“停止一切”，而是“冻结 RC 的功能范围、只放行关键修复”，通过迭代 RC 的方式在发布前把质量问题收敛掉。

完整时间线：6 + 3 = 9 周

原文档给出了一个 ASCII 时间轴图，这是理解整个发布流程最直观的素材，完整保留如下：

Codebase Release Start of is frozen (end of the Cycle (7th week) 9th week) +---------------------------------------+---------------------+ | | | | Development phase | Freeze phase | | | | +---------------------------------------+---------------------+ 6 weeks 3 weeks <---------------------------------------><-------------------->

注意图中“Codebase is frozen”标在第 7 周：文档正文说“六周之后”冻结，而图上的“7th week”指的是第 7 周开始（即第 6 周结束）进入冻结阶段，两者是一致的。整条时间线可归纳为：

如何在冻结日前最大化被合入的概率？

原文档明确强调：永远不存在“某个变更集一定被合入”的保证。但存在一系列可操作的做法，能显著提高 PR 在冻结前被合并的概率：

1. 对齐 Roadmap：团队会优先评审与路线图一致的 PR。在本仓库中，路线图文件就是仓库根部的 ROADMAP.md（文档正文明确提到 “usually defined by a ROADMAP.md file at the root of the repository”）。该文件列出了运行时改进、BuildKit 集成、Rootless Mode、测试迁移、内部解耦等优先事项。
2. 越早开 PR 越好：PR 开得越早，维护者评审时间越充裕。原文档给了一个极端反例：如果 PR 在冻结日前一天才打开，几乎不可能赶上本版合并。
3. 持续与维护者沟通：通过邮件列表、IRC、GitHub issues 等渠道尽早获得设计层面的早期反馈，可以减少后续评审来回讨论的时间。
4. 让代码“自带说服力”：代码有注释、有完整测试、并且完全遵守 CONTRIBUTING 指南 中的每一条规则，能显著加快评审速度。

仓库中 CONTRIBUTING.md 的“Quick contribution tips”部分（如 gofmt 格式化、提交测试、commit message 规范、LGTM 评审机制等）正是文档所称 “every single rules” 的具体展开，二者配套阅读效果最佳。

发布执行：第 9 周末所有项目一起发布

冻结期结束时（周期开始后的第 9 周末），所有子项目在同一天一起发布。这是 Docker 发布流程最显著的特色：虽然 Engine、Compose、Swarm、Distribution 等各自独立开发、独立仓库，但对外发布的节奏是强对齐的，避免出现“Engine 新版本已经可用但 Compose 还停在旧版”的错位，也方便发行版打包者一次性同步所有组件。

在本仓库中，这种“一起发布”的执行侧基础设施同样可见：

• hack/make.sh 是 Engine 的官方构建脚本，其DEFAULT_BUNDLES默认产物包括binary-daemon、dynbinary、test-integration、test-docker-py、cross；脚本注释强调版本号取自仓库根部的VERSION文件，并将 git commit hash 一并编入二进制（工作区不干净时追加-unsupported后缀）；
• 顶层 Makefile 提供deb、rpm、static等打包目标，统一用根目录VERSION作为版本号；
• components/engine/hack/make/ 目录下每个脚本对应一个 bundle（binary、dynbinary、test-integration等），正如其 README 所述，这些脚本“不应被直接调用”，而应作为参数传给hack/make.sh。

例外情况：关键问题导致发布推迟

原文档给出了唯一的例外路径：

如果冻结期结束时发现了关键问题，且需要更多时间处理，那么本次发布会被推迟（pushed back）。

而推迟发布有一个连带效应：下一个发布周期同样会顺延。这是因为周期是首尾衔接的（上一个发布日即下一个周期起点），一旦当前发布晚发，下一周期也随之晚开始。这一规则保证了“推迟”不会压缩下一个周期的开发时间，从而避免把质量风险滚动传导到后续版本。

纵深：配套的分支与标签规范

RELEASE-PROCESS.md描述的“RC 迭代”“cherry-pick 进 RC”“同一天发布”等机制，在配套文档 BRANCHES-AND-TAGS.md 中有对应的落地约定。该文档规定 docker/docker 仓库通常只保留三个常驻分支：

• docs分支：在两次产品发布之间承载文档更新，把文档发布与产品发布解耦；
• release分支：存放项目最近一次已发布版本的代码。它的更新机制与冻结期直接挂钩——每次公开发布由一条针对release分支的 PR 承载，这条 PR “活在”整个代码冻结期内，当它被合并时，release分支随之更新，并将其新状态打上对应 tag；
• master：常规开发主线。

标签（tag）规范同样与 RC 机制吻合，格式为vX.Y.Z[-suffix[N]]：

• X、Y、Z必须全部给出，例如v1.0.0；
• 版本1.8.0的第一个发布候选应打v1.8.0-rc1；
• 某产品的第二个 alpha 版本应打v1.0.0-alpha1。

此外，任何公开发布的编译产物（nightly 构建除外）都应有对应的 tag。这套命名规则与 RELEASE-PROCESS 的 RC 迭代策略相互印证：rcN后缀的递增正是“RC 内容变化就放新版本”的标签化体现。

纵深：补丁（patch）发布流程

主文档着眼于“大版本”的 9 周节奏，而 PATCH-RELEASES.md 补齐了“小版本”的路径，二者共同构成完整的发布体系：

• 每次发布（含主版本vX.Y.0与补丁版本vX.Y.Z）之后，都会创建一个补丁发布里程碑vX.Y.Z+1，用于收集“可能值得一次补丁发布”的 issue 与 PR；
• 补丁发布只能包含 bug 修复，绝不包含新特性；只有回归（regression）才应被加入里程碑；
• 主版本的release captain同时负责补丁发布，并与其他维护者按周评审里程碑，为 issue 分配priority/标签：
  • P0：关键问题，必须指派维护者，应力争一周内修复；
  • P1：重大但非关键问题，必须指派维护者；
  • P2 / P3：其他问题，可指派维护者；
• 决定是否发布补丁：只有 P0 才有资格触发补丁发布，P1～P3 不应影响决策；若下一主版本临近，release captain 可取消补丁发布，把补丁并入即将到来的主版本；
• 补丁内容选择：所有 P0 修复必须包含；部分 P1～P3 修复可视严重程度与风险包含。经验法则是——只挑小补丁、只挑问题理解透彻的修复、必须带可验证的测试，目标是“让大量用户受益且零概率损害任何人的体验”。

总结：这套流程给开发者的三点启示

1. 节奏即承诺：9 周时间制把“发布”从不可预测的工程事件变成可规划的日历事件，代价是功能合入需要严格卡住“冻结日”这个截止点；
2. 冻结不是停摆：master持续开发、RC 迭代发布、关键修复 cherry-pick，冻结期本质上是一个“功能收敛 + 质量收敛”的双轨机制；
3. 推迟是慎用工具：只有关键问题才触发推迟，且推迟必然顺延下一周期，防止质量风险跨版本堆积。

对于想要贡献的开发者，行动清单很明确：早开 PR、对齐 ROADMAP.md、按 CONTRIBUTING.md 规范补全注释与测试、与维护者提前沟通设计，并在冻结日之前完成这一切——那么你的变更就有最大可能随下一批组件一起面世。

• 容器运行时
• 云原生