Envoy 版本发布全流程解析从活跃开发、季度主版本到安全补丁回移【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoyEnvoy 采用单主干 稳定分支的发布模型日常开发集中在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.mdFix Lead安全团队成员负责协调整个发布过程包括识别本次发布需要修复的问题、与 Envoy 社区沟通以及执行发布的具体机制。各季度值班安排Release Manager / Fix Lead如下季度Release ManagerFix Lead2020 Q1Piotr Sikora—2020 Q2Piotr Sikora—2020 Q3Yuchen Dai—2020 Q4Christoph Pakulski—2021 Q1Rei Shimizu—2021 Q2Dmitri Dolguikh—2021 Q3Takeshi Yoneda—2021 Q4Otto van der Schaaf—2022 Q1Otto van der SchaafRyan Hamilton2022 Q2Pradeep RaoMatt Klein2022 Q4Can CecenTony Allen2023 Q3Boteng YaoKateryna Nezdolii2023 Q4Paul MerrisonBrian Sonnenberg2024 Q2Ryan NortheyBoteng Yao2024 Q3Ryan NortheyBoteng Yao2025 Q1Ryan NortheyBoteng Yao2025 Q3Ryan NortheyYan Avlasov2025 Q4Ryan NortheyBoteng Yao2026 Q1Ryan NortheyBoteng Yao2026 Q2Ryan NortheyBoteng Yao2026 Q3Kateryna NezdoliiYan Avlasov五、主版本发布计划表Major release schedule为照顾下游项目Envoy 采用固定发布计划每个季度的第 15 天发布新版本允许最多延迟 2 周硬性截止时间为 3 周。各版本的计划/实际发布时间及生命周期End of Life即该版本失去支持的时间点如下版本计划日期实际日期差异生命周期结束1.12.02019/09/302019/10/3131 天2020/10/311.13.02019/12/312020/01/2020 天2021/01/201.14.02020/03/312020/04/088 天2021/04/081.15.02020/06/302020/07/077 天2021/07/071.16.02020/09/302020/10/088 天2021/10/081.17.02020/12/312021/01/1111 天2022/01/111.18.02021/03/312021/04/1515 天2022/04/151.19.02021/06/302021/07/1313 天2022/07/131.20.02021/09/302021/10/055 天2022/10/051.21.02022/01/152022/01/12-3 天2023/01/121.22.02022/04/152022/04/150 天2023/04/151.23.02022/07/152022/07/150 天2023/07/151.24.02022/10/152022/10/194 天2023/10/191.25.02023/01/152023/01/183 天2024/01/181.26.02023/04/152023/04/183 天2024/04/181.27.02023/07/142023/07/2713 天2024/07/271.28.02023/10/162023/10/193 天2024/10/191.29.02024/01/162024/01/160 天2025/01/161.30.02024/04/162024/04/160 天2025/04/161.31.02024/07/162024/07/193 天2025/07/191.32.02024/10/152024/10/150 天2025/10/151.33.02025/01/142025/01/140 天2026/01/141.34.02025/04/152025/04/150 天2026/04/151.35.02025/07/152025/07/238 天2026/07/231.36.02025/10/142025/10/140 天2026/10/141.37.02026/01/132026/01/130 天2027/01/131.38.02026/04/142026/04/239 天2027/04/231.39.02026/07/142026/07/140 天2027/07/141.40.02026/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 Q22024/06/042024/06/040 天2024 Q32024/09/032024/09/1916 天2024 Q42024/12/032024/12/1815 天2025 Q12025/03/042025/03/2016 天2025 Q22025/06/03——2025 Q32025/09/022025/09/031 天2025 Q42025/12/022025/12/031 天2026 Q12026/03/032026/03/107 天2026 Q22026/06/022026/06/2422 天2026 Q32026/08/18——2026 Q32026/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），仅供参考