Envoy 版本发布全流程解析：从活跃开发、季度主版本到安全补丁回移
【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy
Envoy 采用"单主干 + 稳定分支"的发布模型：日常开发集中在main分支，每季度从main切出一个主版本，同时在 12 个月维护窗口内对稳定分支进行安全与稳定性修复的回移（backport）。本文以仓库根目录的 RELEASES.md 为主线，结合 BACKPORTS.md、maintainer/RELEASE.md、ci/reopen_branch.sh 等配套文件，完整讲解 Envoy 的版本发布周期、回移规则、发布角色分工以及"切主版本"的端到端实操步骤，帮助读者理解 Envoy 版本节奏并掌握参与回移提交流程的能力。
一、发布模型总览：活跃开发与稳定发布
Envoy 的发布流程围绕两类分支展开：
- 活跃开发（Active development）：所有日常开发都发生在
main分支上，新版本直接从main发布。仓库当前main的版本号记录在根目录 VERSION.txt（目前为1.40.0-dev，-dev后缀表示处于开发模式）。 - 稳定发布（Stable releases）：从
main分支或既有稳定分支上产生，具体包含三类：
| 发布类型 | 说明 |
|---|---|
| 主版本（Major） | 直接由main分支创建新版本 |
| 次版本（Minor） | 针对处于扩展维护窗口（过去 12 个月内发布的任何版本）的版本，回移来自main的安全修复（含不构成 CVE 的安全修复）与稳定性修复（任何可能导致崩溃的问题，包括由受信任控制平面触发的崩溃） |
| 补丁修复（Bugfix） | 稳定版本维护者认为值得修复的 bug，按需（ad-hoc）发布 |
主版本每季度发布一次并遵循下文的时间表；安全修复通常也按季度进行，但具体取决于安全 bug 的数量与严重程度；其他发布则是"尽力而为"的临时性发布。
二、安全发布（Security releases）
关键安全修复由 Envoy 安全团队负责，安全团队先为main分支提供修复；修复就绪后，稳定发布维护者再将其回移到其余受支持的稳定发布版本。
需要特别注意的是：零日漏洞以及以保密（embargo）形式向我们披露的上游漏洞，可能需要在几乎没有预警的情况下触发紧急发布。因此安全发布的实际日期只能作为参考，无法完全固定。
安全发布的节奏与主版本错开，采用 3 个月周期、大约位于两个主版本中间的时间点发布（详见下文"安全发布计划表"）。
三、Backports：稳定分支回移机制
稳定分支的修复来源于main分支，通过回移（backport）机制进入稳定分支。
3.1 提名与审批
除安全团队直接负责的安全修复外，其他安全和可靠性修复都可以通过给 PR 添加backport/review标签来提名回移。该标签可以由 repokitteh 机器人的/backport命令自动添加——仓库根目录的 repokitteh.star 中定义了handlers.command(name = "backport", ...)处理器，其行为就是调用github.issue_label("backport/review")。
只有安全和可靠性修复会被回移，所以提交者在提议回移之前需要认真评估改动性质。
3.2 直接提交回移 PR
除了通过标签提名，也可以直接针对相关发布分支（如release/v1.37）提交回移 PR。需要注意的规则包括：
- 回移时应面向所有受影响的受支持分支分别提交；
- 回移 PR 应从
main分支挑选具体提交（cherry-pick），并保持提交的独立性，同时跟踪上游发布分支； - 变更应使用rebase 而非 merge来管理，如需调整，应将调整 squash 进相关提交；
- 发布分支会按照下文的安全发布计划发布，并在
main发布（主版本）之前立即创建。
3.3 回移轮值团队的操作职责
BACKPORTS.md 进一步明确了回移轮值人员的职责：回移轮值人员负责为安全发布及其他符合条件的回移执行回移工作，需要拥有 triage 权限，并定期对带有backport/review标签的 issue 进行分类——要么移除backports-review标签并添加backports-approved，要么在评论中说明该 issue 不符合 RELEASES.md 规定的回移条件。
对于已批准的 PR，轮值人员应基于 RELEASES.md 中的支持窗口（12 个月），将其回移到所有受支持的二进制版本分支。回移 PR 的评审应发送给原 PR 作者和/或评审者。安全回移的最佳实践是：先为每个回移单独创建一个 patch，确保各自通过 CI；再创建一个合并后的 rollup patch，确保整体能干净合入。当维护团队启动安全发布时，Fix Lead 应将回移轮值人员加入该发布专用的 Slack 频道，并将标有cve/next的 issue 合入main后由回移人员负责回移到受支持版本。
四、发布管理：角色与季度轮值表
主版本由值班维护者（maintainer on-call）处理，不涉及任何回移。安全发布则由Release Manager（发布经理）和Fix Lead（修复负责人）协同完成：
- Release Manager：负责审批和合并回移，具体职责见 BACKPORTS.md；
- Fix Lead：安全团队成员，负责协调整个发布过程，包括识别本次发布需要修复的问题、与 Envoy 社区沟通以及执行发布的具体机制。
各季度值班安排（Release Manager / Fix Lead）如下：
| 季度 | Release Manager | Fix Lead |
|---|---|---|
| 2020 Q1 | Piotr Sikora | — |
| 2020 Q2 | Piotr Sikora | — |
| 2020 Q3 | Yuchen Dai | — |
| 2020 Q4 | Christoph Pakulski | — |
| 2021 Q1 | Rei Shimizu | — |
| 2021 Q2 | Dmitri Dolguikh | — |
| 2021 Q3 | Takeshi Yoneda | — |
| 2021 Q4 | Otto van der Schaaf | — |
| 2022 Q1 | Otto van der Schaaf | Ryan Hamilton |
| 2022 Q2 | Pradeep Rao | Matt Klein |
| 2022 Q4 | Can Cecen | Tony Allen |
| 2023 Q3 | Boteng Yao | Kateryna Nezdolii |
| 2023 Q4 | Paul Merrison | Brian Sonnenberg |
| 2024 Q2 | Ryan Northey | Boteng Yao |
| 2024 Q3 | Ryan Northey | Boteng Yao |
| 2025 Q1 | Ryan Northey | Boteng Yao |
| 2025 Q3 | Ryan Northey | Yan Avlasov |
| 2025 Q4 | Ryan Northey | Boteng Yao |
| 2026 Q1 | Ryan Northey | Boteng Yao |
| 2026 Q2 | Ryan Northey | Boteng Yao |
| 2026 Q3 | Kateryna Nezdolii | Yan Avlasov |
五、主版本发布计划表（Major release schedule）
为照顾下游项目，Envoy 采用固定发布计划：每个季度的第 15 天发布新版本，允许最多延迟 2 周，硬性截止时间为 3 周。各版本的计划/实际发布时间及生命周期（End of Life，即该版本失去支持的时间点）如下：
| 版本 | 计划日期 | 实际日期 | 差异 | 生命周期结束 |
|---|---|---|---|---|
| 1.12.0 | 2019/09/30 | 2019/10/31 | +31 天 | 2020/10/31 |
| 1.13.0 | 2019/12/31 | 2020/01/20 | +20 天 | 2021/01/20 |
| 1.14.0 | 2020/03/31 | 2020/04/08 | +8 天 | 2021/04/08 |
| 1.15.0 | 2020/06/30 | 2020/07/07 | +7 天 | 2021/07/07 |
| 1.16.0 | 2020/09/30 | 2020/10/08 | +8 天 | 2021/10/08 |
| 1.17.0 | 2020/12/31 | 2021/01/11 | +11 天 | 2022/01/11 |
| 1.18.0 | 2021/03/31 | 2021/04/15 | +15 天 | 2022/04/15 |
| 1.19.0 | 2021/06/30 | 2021/07/13 | +13 天 | 2022/07/13 |
| 1.20.0 | 2021/09/30 | 2021/10/05 | +5 天 | 2022/10/05 |
| 1.21.0 | 2022/01/15 | 2022/01/12 | -3 天 | 2023/01/12 |
| 1.22.0 | 2022/04/15 | 2022/04/15 | 0 天 | 2023/04/15 |
| 1.23.0 | 2022/07/15 | 2022/07/15 | 0 天 | 2023/07/15 |
| 1.24.0 | 2022/10/15 | 2022/10/19 | +4 天 | 2023/10/19 |
| 1.25.0 | 2023/01/15 | 2023/01/18 | +3 天 | 2024/01/18 |
| 1.26.0 | 2023/04/15 | 2023/04/18 | +3 天 | 2024/04/18 |
| 1.27.0 | 2023/07/14 | 2023/07/27 | +13 天 | 2024/07/27 |
| 1.28.0 | 2023/10/16 | 2023/10/19 | +3 天 | 2024/10/19 |
| 1.29.0 | 2024/01/16 | 2024/01/16 | 0 天 | 2025/01/16 |
| 1.30.0 | 2024/04/16 | 2024/04/16 | 0 天 | 2025/04/16 |
| 1.31.0 | 2024/07/16 | 2024/07/19 | +3 天 | 2025/07/19 |
| 1.32.0 | 2024/10/15 | 2024/10/15 | 0 天 | 2025/10/15 |
| 1.33.0 | 2025/01/14 | 2025/01/14 | 0 天 | 2026/01/14 |
| 1.34.0 | 2025/04/15 | 2025/04/15 | 0 天 | 2026/04/15 |
| 1.35.0 | 2025/07/15 | 2025/07/23 | +8 天 | 2026/07/23 |
| 1.36.0 | 2025/10/14 | 2025/10/14 | 0 天 | 2026/10/14 |
| 1.37.0 | 2026/01/13 | 2026/01/13 | 0 天 | 2027/01/13 |
| 1.38.0 | 2026/04/14 | 2026/04/23 | +9 天 | 2027/04/23 |
| 1.39.0 | 2026/07/14 | 2026/07/14 | 0 天 | 2027/07/14 |
| 1.40.0 | 2026/10/13 | — | — | — |
从表中可以看出，近两年 Envoy 基本能做到按计划日期准点发布（多个版本差异为 0 天）；1.40.0 计划于 2026/10/13 发布，这也是当前仓库 VERSION.txt 处于1.40.0-dev开发模式所对应的下一个主版本。
六、Cutting a major release：切主版本完整实操
"Cutting a major release" 是值班维护者发布主版本的标准流程，RELEASES.md 将其拆解为如下步骤：
- 检查里程碑 issue：查看标记了当前发布里程碑的未关闭 issue，等待其修复完成，或将其顺延到下一个里程碑；
- 冻结高风险合并：要求维护者暂停合并任何高风险 PR，直到版本被打 tag——这是为了保证
main分支始终保持在"release candidate 质量"水平； - 终检发布说明片段（release note fragments）：检查 changelogs/current 目录下的变更说明片段：
- 修正必要的语法、标点和格式问题；
- 检查安全/稳定版本的发布说明是否被重复写入了主版本的发布说明（不应重复）；
- 通过
bazel run @envoy_repo//:release将仓库切换到"release 模式"，该工具会创建一个包含发布所需变更的提交； - 更新 RELEASES 文档中的相关日期；同时确保下个季度已有稳定的维护者报名，并在发布计划中记录下一版本的截止日期；
- 获得评审并合并；
- 提交 PR 并等待测试通过：用上述提交创建 PR，等待所有测试通过；
- CI 自动发布：PR 合入后，CI 会自动创建带 tag 的发布及对应的发布分支；
- 切回开发模式：运行
bazel run @envoy_repo//:dev创建继续开发所需的提交，并再次提交 PR； - 运行弃用清理脚本：执行
bazel run //tools/deprecate_guards:deprecate_guards（对应 tools/deprecate_guards 目录中的脚本）； - 公告发布：向 envoy-announce、envoy-users、envoy-dev、envoy-maintainers 邮件列表发送公告邮件（附上最新 release 页面链接），并在
#envoy-dev、#envoy-usersSlack 频道同步发布。
6.1 release / dev 工具的行为细节
maintainer/RELEASE.md 对上述bazel run @envoy_repo//:release与bazel run @envoy_repo//:dev做了更细致的说明：
release命令：移除 VERSION.txt 中的-dev后缀，并将 changelogs/current.yaml 的日期设置为当天 UTC 日期；默认还会附带执行sync动作（可用--nosync关闭），完成后自动提交（可用--nocommit关闭）；只能在开发模式下运行，且分支处于 release 模式时不应再有任何改动。dev命令：将版本号递增并添加-dev后缀，把changelogs/current.yaml改名为changelogs/$VERSION.yaml，再从模板创建新的changelogs/current.yaml；对非main的发布分支（如release/v1.23），可通过--patch选项只递增 patch 版本号而不是 minor 版本号；同样只能在 release 模式下运行。sync命令：同步较早的发布分支——拉取新版本的 changelog（对旧版 rst 格式做解析）、拉取新可用的 rst 对象/链接清单（用于文档中的版本映射）、更新 docs/versions.yaml。该命令通常用于将新版本同步到main以更新 "latest" 文档。
6.2 分支开合工作流
maintainer/RELEASE.md 还给出了完整的分支工作流：
- 发布新 minor 版本（
main发布）：forkmain→ 运行bazel run @envoy_repo//:release→ 提交 PR → 等 PR 合入main并打 tag（此时main处于 release 模式，不应再有新提交）→ forkmain→ 运行bazel run @envoy_repo//:dev→ 提交 PR → 继续开发。 - 发布新 patch 版本（
vX.Y发布）：以release/v1.23分支为例，fork 该分支 → 运行bazel run @envoy_repo//:release→ 提交 PR 到release/v1.23→ 等 PR 合入并打 tag → fork 后运行bazel run @envoy_repo//:dev -- --patch→ 提交 PR → 继续开发。 - 同步发布分支：当较早的发布分支（如
release/v1.21）发布v1.21.7后，可在所有后续分支（release/v1.22、release/v1.23……main）中运行bazel run @envoy_repo//:sync，以同步 changelog 与文档映射。
仓库中的 ci/reopen_branch.sh 是这套流程的自动化实现之一：脚本确认当前位于main分支后，运行bazel run @envoy_repo//:dev生成 dev 提交，并从 VERSION.txt 解析出release/vX.Y分支名推送到远端，从而完成"重开分支"。
七、安全发布计划表（Security release schedule）
安全发布采用 3 个月周期，时间点大约位于两个主版本中间。历史计划与实际发布时间如下：
| 季度 | 计划日期 | 实际日期 | 差异 |
|---|---|---|---|
| 2024 Q2 | 2024/06/04 | 2024/06/04 | 0 天 |
| 2024 Q3 | 2024/09/03 | 2024/09/19 | +16 天 |
| 2024 Q4 | 2024/12/03 | 2024/12/18 | +15 天 |
| 2025 Q1 | 2025/03/04 | 2025/03/20 | +16 天 |
| 2025 Q2 | 2025/06/03 | — | — |
| 2025 Q3 | 2025/09/02 | 2025/09/03 | +1 天 |
| 2025 Q4 | 2025/12/02 | 2025/12/03 | +1 天 |
| 2026 Q1 | 2026/03/03 | 2026/03/10 | +7 天 |
| 2026 Q2 | 2026/06/02 | 2026/06/24 | +22 天 |
| 2026 Q3 | 2026/08/18 | — | — |
| 2026 Q3 | 2026/09/29 | — | — |
表中 2026 Q3 出现两个计划日期（8/18 与 9/29），反映出安全发布受漏洞数量与严重程度影响、日期需要动态调整的现实。
八、与发布配套的仓库设施
Envoy 仓库为发布流程提供了完整的配套设施，可从以下路径继续深入：
- 版本号：VERSION.txt（当前
1.40.0-dev）； - 变更说明组织结构：changelogs/changelogs.yaml 定义了合法的 changelog 分区（
changes、behavior_changes、minor_behavior_changes、bug_fixes、removed_config_or_runtime、new_features、deprecated）以及areas规范（文件名中/必须以~编码）；changelogs/current 下按behavior_changes、bug_fixes、deprecated、minor_behavior_changes、new_features、removed_config_or_runtime分目录存放每个 PR 的.rst片段（例如new_features/下以area__slug.rst命名的文件）；历史版本则归档为changelogs/1.X.Y.yaml； - 回移标签自动化：repokitteh.star 中定义了
/backport、/milestone、/nostalebot等命令处理器； - 发布/开发模式切换工具：maintainer/RELEASE.md 中
@envoy_repo//:release、@envoy_repo//:dev、@envoy_repo//:sync的完整说明与输出示例； - 分支重开脚本：ci/reopen_branch.sh；
- 弃用守卫清理：tools/deprecate_guards。
总而言之，Envoy 的发布体系以"12 个月维护窗口 + 每季度主版本 + 每季度安全发布"为骨架，通过backport/review标签、@envoy_repo//:release|dev|sync三个 Bazel 工具与 CI 自动打 tag 机制，把"活跃开发—版本冻结—回移维护—发布公告"的完整生命周期固化成了可重复执行的标准流程。无论是希望了解 Envoy 版本节奏的下游使用者，还是想要参与回移提交的贡献者，都可以依据本文与 RELEASES.md 快速上手。
【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
