etcd项目版本发布全流程指南
前言
作为分布式键值存储系统的核心组件,etcd的版本发布流程需要严格把控。本文将深入解析etcd项目的版本发布机制,帮助开发者理解从版本规划到最终发布的完整生命周期。
版本管理机制
etcd采用语义化版本控制(SemVer 2.0.0)规范,版本号格式为主版本号.次版本号.修订号
。项目设有专门的发布管理团队,负责各版本的发布工作。
版本类型区分
-
主/次版本发布:包含新功能和重大改进
- 需确保相关里程碑(Milestone)已完成
- 更新升级文档
- 必要时调整MinClusterVersion
- 添加新版本特性映射表
-
预发布版本:用于功能预览和测试
- 遵循
主版本号.次版本号.修订号-预发布标识
格式 - 如3.6.0-alpha.1、3.6.0-beta.2等
- 遵循
-
修订版本发布:仅包含错误修复和安全更新
- 通过cherry-pick方式将修复提交到稳定分支
- 每个新修订版本必须严格优于前一个版本
发布标准
etcd项目在以下情况下会发布新修订版本:
- 修复了重要安全问题
- 解决了关键性功能缺陷
- 累计修复3个以上主要问题
- 累计修复5个以上次要问题
发布前准备
环境配置
- GPG密钥:生成并配置GPG密钥用于Git标签签名
- Linux环境:确保具备以下条件:
- 安装匹配
.go-version
文件要求的Golang版本 - 配置非特权用户可执行docker命令
- 预留至少5GB磁盘空间
- 安装匹配
- 工具安装:
- gsutil工具(用于Google Cloud存储操作)
- gh工具(GitHub命令行工具)
认证配置
- 容器仓库认证:
gcloud auth login gcloud auth configure-docker
- GitHub认证:
gh auth login
正式发布流程
发布前1天
- 创建发布计划issue,说明发布时间和内容
- 提交PR将发布团队成员加入release-etcd GitHub团队
发布当天
-
容器仓库登录验证:
docker login gcr.io docker login quay.io
-
获取代码:
git clone --branch release-3.X git@github.com:etcd-io/etcd.git
-
执行发布脚本:
- 正式版本:
DRY_RUN=false ./scripts/release.sh 3.5.13
- 预发布版本:
DRY_RUN=false BRANCH=main ./scripts/release.sh 3.6.0-alpha.2
- 正式版本:
-
发布GitHub Release:
- 编辑脚本生成的草稿Release
- 根据版本类型勾选相应选项
- 发布前仔细检查内容
-
邮件通知:
- 发送发布通知到etcd-dev邮件组
- 请邮件组管理员审核发布邮件
-
后续操作:
- 更新变更日志中的发布日期
- 关闭发布计划issue
- 清理GitHub release团队权限
- 如为新主/次版本,创建稳定分支
常见问题处理
-
二进制文件上传超时:
- 重新运行相同命令即可,已上传文件会被覆盖更新
-
镜像推送超时:
- 添加
--no-upload
参数重新运行脚本 - 镜像上传会从中断处继续
- 添加
-
GPG签名问题:
- 目前发布脚本仅支持GPG签名
- 如使用SSH签名需临时禁用相关配置
发布说明编写规范
- 概述:简要说明本版本的主要改进和修复
- PR引用:使用
[GH XXXX]
格式引用相关PR - 变更摘要:基于
release-note
标签整理用户可见变更
最佳实践建议
- 版本规划:提前规划发布周期,预留足够的测试时间
- 变更跟踪:使用Milestone功能跟踪版本相关issue
- 回滚准备:制定详细的回滚方案,应对可能的发布问题
- 文档同步:确保版本发布与文档更新同步进行
通过遵循上述流程,etcd项目能够保持稳定、可靠的版本发布节奏,为用户提供高质量的分布式存储解决方案。
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考