菜单

发布流程

相关源文件

本文档详细介绍了 etcd 项目的发布流程,包括发布新版本 etcd 所遵循的步骤、角色和程序。它涵盖了版本的发布、规划、准备、执行和公告。有关从源代码构建的信息,请参阅 构建与测试

概述

etcd 项目遵循 semver.org 定义的语义化版本控制 (MAJOR.MINOR.PATCH)。发布流程包括由指定发布团队管理的规划、准备、执行和公告阶段。不同类型的发布(主要、次要、补丁或预发布版本)流程略有不同。

发布管理团队

发布管理由一个指定贡献者团队负责,该团队负责主要/次要版本以及稳定分支的补丁。当前团队由 James Blair 和 Ivan Valdes Castillo 领导,成员如下:

  • Benjamin Wang
  • Fu Wei
  • James Blair
  • Ivan Valdes Castillo
  • Marek Siarkowicz
  • Sahdev Zala
  • Siyuan Zhang
  • Wenjia Zhang

发布流程

下图展示了高层次的发布流程

来源:Documentation/contributor-guide/release.md38-122

版本控制方案

etcd 遵循语义化版本控制,包含以下版本组件:

  1. 主版本 (X.0.0):包含不兼容的 API 更改
  2. 次版本 (X.Y.0):以向后兼容的方式添加功能
  3. 补丁版本 (X.Y.Z):向后兼容的错误修复

预发布版本

在主版本或次版本发布之前,etcd 会发布预发布版本。

  1. Alpha 版本 (X.Y.0-alpha.N):早期测试版本,可能包含不稳定的功能
  2. Beta 版本 (X.Y.0-beta.N):比 alpha 版本更稳定,功能基本完整
  3. 发布候选版本 (X.Y.0-rc.N):稳定发布前的最终测试版本

来源:CHANGELOG/CHANGELOG-3.6.md6-177 CHANGELOG/CHANGELOG-3.5.md1-206

分支管理

etcd 的分支管理遵循特定的模式,以促进发布流程

  • 主分支:所有新开发在此进行
  • 发布分支 (release-X.Y):为每个稳定的次版本创建
  • 标签:为每个特定发布的版本创建

来源:Documentation/contributor-guide/branch_management.md1-26

特性生命周期

etcd 中的功能会经历一个定义好的生命周期,这会影响发布流程

来源:Documentation/contributor-guide/features.md1-87

补丁发布标准

满足以下任一条件时,将发布新的补丁版本:

  • 修复了一个或多个主要 CVE(>=7.5)
  • 修复了一个或多个严重 bug
  • 修复了三个或更多主要 bug
  • 修复了五个或更多次要 bug

来源:Documentation/contributor-guide/release.md44-52

发布先决条件

执行发布前,请确保以下事项:

  1. 生成 GPG 密钥并将其添加到您的 GitHub 账户
  2. 设置一台 Linux 机器,安装:
    • Git
    • Golang(与 .go-version 中指定的版本匹配)
    • Docker
  3. 安装 gsutil 以访问 Google Cloud Storage
  4. 对镜像仓库进行身份验证
    • docker login gcr.io
    • docker login quay.io
  5. 安装 GitHub CLI (gh) 并进行身份验证

来源:Documentation/contributor-guide/release.md53-71

发布流程步骤

执行发布的详细步骤如下:

  1. 发起一个 issue 来发布发布计划
  2. 确保发布团队成员拥有 etcd-io GitHub 组织的访问权限
  3. 验证对镜像仓库的身份验证
  4. 克隆 etcd 仓库并检出目标分支
  5. 运行发布脚本
    对于预发布版本,使用:
  6. 发布 GitHub 发布草稿
  7. 在 etcd-dev Google 群组中宣布
  8. 更新 changelog,包含正确的发布日期
  9. 关闭发布计划 issue
  10. 重置发布团队的 GitHub 权限
  11. 如果这是新的主版本/次版本发布,则创建一个新的稳定分支
  12. 如有必要,轮换密码

来源:Documentation/contributor-guide/release.md72-123 scripts/release.sh

常见的发布问题

发布期间可能出现的一些已知问题:

  1. 推送二进制文件超时:如果推送到 Google Cloud Storage 超时,请重新运行脚本 - 上传将继续。
  2. 推送镜像超时:如果容器镜像上传失败,请使用 --no-upload 标志重新运行。
  3. GPG 与 SSH 签名:发布脚本需要 GPG 签名,而不是 SSH 签名。

来源:Documentation/contributor-guide/release.md125-131

变更日志管理

每次发布都需要在相应的 CHANGELOG 文件中有一个格式正确的 changelog 条目。

  1. 撰写介绍,突出主要更改
  2. 使用 [GH XXXX] 格式引用 pull request
  3. 包含 pull request 的链接
  4. 按组件或类型对更改进行分组

示例 changelog 结构

  • 破坏性变更
  • etcd 服务器
  • 软件包 clientv3
  • 指标、监控
  • 依赖项
  • Go 版本

来源:CHANGELOG/CHANGELOG-3.5.md1-206 CHANGELOG/CHANGELOG-3.6.md6-177 Documentation/contributor-guide/release.md38-43

生产环境建议

etcd 项目维护着关于哪些版本对生产环境稳定和安全的要求。目前,生产环境的最低推荐版本为 v3.4.22+ 和 v3.5.6+。

来源:CHANGELOG/README.md1-22