etcd 分支管理实践main 开发分支、release-X.Y 稳定分支与滚动发布模型【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcdetcd 采用滚动发布模型rolling release model管理其 Git 分支main是唯一开发分支所有新功能先落地于此每个 minor 版本发布后会冻结出一条release-X.Y稳定分支社区仅维护最近两个稳定版本补丁patch以 cherry-pick 方式回合。读完本文你可以理解 etcd 的版本分支体系、判断一个 PR 应该针对哪个分支提交并掌握从 main 切出新稳定分支、以及向稳定分支回移修复的完整机制。一、滚动发布模型总览etcd 团队采用了滚动发布模型并支持两个稳定版本two stable versions的 etcd。其核心规则如下源自 Documentation/contributor-guide/branch_management.md新开发工作发生在main分支上main分支必须始终保持绿色构建green build向后兼容的 bug 修复应针对main分支提交随后被回合port到稳定分支当main分支准备好发布时它会被打上 tag并成为新的稳定分支。所有版本号遵循 语义化版本 2.0.0而 api/version/version.go 中维护着当前 main 分支的版本常量与集群兼容版本// MinClusterVersion is the min cluster version this etcd binary is compatible with. MinClusterVersion 3.0.0 Version 3.8.0-alpha.0当前 main 分支的版本号带有-alpha.0后缀这正是main 是预发布/开发分支这一分支管理策略的直接体现main 上的版本总是下一个 minor 版本的 alpha 预发布直到正式发布被 tag 出去。同一文件中还定义了V3_0到V4_0的完整版本枚举api/version/version.go供集群混合版本mixed-version逻辑使用。二、main 开发分支main分支是 etcd 的开发分支所有新功能new features都首先在这里落地。试验新功能想要尝鲜实验性特性应拉取main分支进行尝试。官方提醒main可能不稳定因为新功能可能引入 bug。Feature freeze功能冻结在下一个稳定版本发布前功能类 PR 会被冻结。会为该 major/minor 版本指派一名发布经理release manager带领 etcd 社区进行为期一到两周的测试、修复与发布文档整理。发布经理团队与具体职责在 Documentation/contributor-guide/release.md 的 Release management 一节有完整说明所有发布版本编号遵循语义化版本 2.0.0major/minor 版本或其预发布发布前需要确认对应 milestone 已完成、升级文档已就绪并在必要时 bump 仓库中硬编码的MinClusterVersion。从 CI 角度看main 分支的绿色构建由 Prow 的 presubmit 任务保障etcd 的 CI 托管在 kubernetes/test-infra 的 Prow 上PR 提交后会自动运行静态检查、单元、集成与 e2e 测试如pull-etcd-e2e-amd64这类任务会针对 main、release-3.6、release-3.5、release-3.4 等分支运行详见 Documentation/contributor-guide/prow_jobs.md。这解释了为什么分支管理规则要求main 必须始终绿色——它是所有稳定分支未来代码的上游。三、稳定分支release- 前缀所有以release-为前缀的分支都被视为稳定分支stable branches例如release-3.4、release-3.5、release-3.6。当前仓库中可观察到从release-0.4到release-3.7的一整排历史稳定分支完整体现了 etcd 自 3.x 时代延续下来的分支命名惯例。稳定分支的生命周期规则每个 minor 版本发布后都会为该版本新建一条稳定分支由**补丁发布经理patch release manager**负责管理社区持续修复最近两个稳定发布中向后兼容的 bug在每个受支持的发布分支上只要存在需要回合的补丁就每两周发布一次 patch 版本。这里的关键约束是只支持最近两个稳定版本当release-3.7与release-3.6同时受支持时release-3.5就不再接收新的 patch 发布。补丁发布的具体门槛在 Documentation/contributor-guide/release.md 的 Patch release criteria 一节给出了量化标准修复了一个或多个重大 CVECVSS ≥ 7.5修复了一个或多个关键 bug修复了三个或更多重要 bug修复了五个或更多次要 bug。满足上述任一条件才值得发布新的 patch 版本配合每两周一次的节奏保证了补丁发布既及时又不泛滥。四、分支是如何诞生的从 main 到新稳定分支branch_management 文档中main 被 tag 后即成为新稳定分支这一句话在仓库的发布流程中对应具体的可执行步骤。4.1 切出稳定分支在 Documentation/contributor-guide/release.md 的 Release steps 第 9 步中写得很明确如果本次是新的 major 或 minor 稳定发布发布完成后通过如下命令创建新的稳定分支git push origin release-${VERSION_MAJOR}.${VERSION_MINOR}也就是说稳定分支不是长期并行开发的而是 main 到达发布点后切分出来的快照之后只接收回合的修复。4.2 发布脚本中的分支语义发布脚本 scripts/release.sh 进一步印证了分支与版本的对应关系if [ -z ${BRANCH:-} ]; then BRANCH$(git rev-parse --abbrev-ref HEAD) else BRANCH${BRANCH:-release-${MINOR_VERSION}} fi脚本从版本号如3.5.13推导出 minor 版本并把默认发布分支解析为release-${MINOR_VERSION}同时脚本会校验 git tag 确实打在${BRANCH}上否则报错终止见 scripts/release.sh。文档中给出的发布命令是# 在仓库根目录执行${VERSION} 为不带 v 前缀的版本号如 3.5.13 DRY_RUNfalse ./scripts/release.sh ${VERSION} # 预发布来自 main 分支的版本如 3.6.0-alpha.2需显式指定 BRANCHmain DRY_RUNfalse BRANCHmain ./scripts/release.sh ${VERSION}注意最后一行预发布alpha/beta/rc从main分支发布而正式 patch 发布从release-X.Y分支发布。这与 api/version/version.go 中 main 分支Version 3.8.0-alpha.0的状态完全吻合——main 产出预发布 tagstable 分支产出正式 tag。仓库构建工具链版本由.go-version当前为 1.26.6约束发布前置条件中也要求本地 Go 版本与该文件保持一致。五、变更如何回移cherry-pick 到稳定分支branch_management 规定向后兼容的 bug 修复先提交到 main随后回合到稳定分支。这个随后回合的机制在 Documentation/contributor-guide/cherry-pick.md 中完整描述有两条路径5.1 自动化路径推荐cherry-pick 主要由k8s-infra-cherrypick-robot处理。在已合并的 PR 下评论目标分支即可/cherry-pick release-3.6机器人会自动创建一个针对目标 release 分支的 cherry-pick PR。注意 release.md 中的约束cherry-pick PR 的提交不应包含 merge commits且内容应严格限定为 bug 修复与安全补丁补丁发布经理会审核这些 PR并从最旧的提交开始按顺序 cherry-pick 到稳定分支保证每个 patch 发布都严格优于其前一个版本。5.2 手动回退路径当自动化机器人不可用时仓库自带了回移脚本 scripts/cherrypick.sh基于 kubernetes 社区的 cherry_pick_pull.sh 改造。先设置远程与环境变量export UPSTREAM_REMOTEupstream # 指向 github.com/etcd-io/etcd 的 remote 名 export FORK_REMOTEorigin # 指向自己 fork 仓库的 remote 名 export GITHUB_USER${github-username}然后将 PR 回移到指定分支并自动发起 PR# 将 PR 12345 cherry-pick 到 release-3.6 并提案为 PR ./scripts/cherrypick.sh ${UPSTREAM_REMOTE}/release-3.6 12345 # 将 12345 和 56789 合并回移作为单个 PR 提案 ./scripts/cherrypick.sh ${UPSTREAM_REMOTE}/release-3.6 12345 56789从源码看scripts/cherrypick.sh脚本要求工作树干净、没有进行中的 rebase/am会校验目标分支是真实存在的远程分支并通过hub工具创建 PR设置DRY_RUN环境变量可跳过 push 和建 PR只把回移的提交留在本地分支中方便制作不打 PR 的补丁。六、对贡献者的实战指引把上述机制落到日常贡献场景可以归纳为一张决策表你要做的事目标分支说明新增功能、API 变更main所有新特性先落地 mainmain 处于 alpha 状态可放心开发修复向后兼容的 bugmain合并后由机器人/经理回合到受支持的release-X.Y请求修复进入稳定版在已合并的 main PR 上评论/cherry-pick release-X.Y仅限 bug 修复与安全补丁不含 merge commit体验最新特性检出main构建可能不稳定不建议生产使用生产环境使用受支持的release-X.Y分支/发布 tag仅最近两个 minor 版本获得 patch 支持几个补充要点feature freeze 期间不要提功能 PR下一个稳定版本发布前一到两周内main 上功能类 PR 冻结只有 bug 修复和文档类变更会被处理此时由该版本的 release manager 主导。stable 分支不做 feature 演进补丁发布经理的职责是维持稳定分支的健康回移内容被严格限制在 bug 修复与安全补丁这与 features 文档中patch 发布不承担 feature 毕业/废弃的规则见 Documentation/contributor-guide/features.md一致。版本联动稳定分支的发布还会触发下游联动——例如 etcd 3.6 补丁需要 bump 到 Kubernetes 1.34 及更新版本3.5 补丁 bump 到 Kubernetes 1.33 及更早受支持版本流程见 Documentation/contributor-guide/bump_etcd_version_k8s.md。这说明 etcd 的分支体系不是孤立的而是与整个 Kubernetes 生态的发布节奏耦合在一起的。七、小结etcd 的分支管理可以浓缩为三条主线main 负责演进新功能、alpha 预发布、feature freeze 管理、release-X.Y 负责稳定每两周一次的 patch 节奏、只支持最近两个 minor 版本、严格限制回移内容、cherry-pick 负责两者之间的桥接机器人自动化优先scripts/cherrypick.sh 手动兜底。理解这套模型后无论是提交 PR、参与发布还是排查版本兼容性都能准确地把变更放到正确的分支上。【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
etcd 分支管理实践main 开发分支、release-X.Y 稳定分支与滚动发布模型【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcdetcd 采用滚动发布模型rolling release model管理其 Git 分支main是唯一开发分支所有新功能先落地于此每个 minor 版本发布后会冻结出一条release-X.Y稳定分支社区仅维护最近两个稳定版本补丁patch以 cherry-pick 方式回合。读完本文你可以理解 etcd 的版本分支体系、判断一个 PR 应该针对哪个分支提交并掌握从 main 切出新稳定分支、以及向稳定分支回移修复的完整机制。一、滚动发布模型总览etcd 团队采用了滚动发布模型并支持两个稳定版本two stable versions的 etcd。其核心规则如下源自 Documentation/contributor-guide/branch_management.md新开发工作发生在main分支上main分支必须始终保持绿色构建green build向后兼容的 bug 修复应针对main分支提交随后被回合port到稳定分支当main分支准备好发布时它会被打上 tag并成为新的稳定分支。所有版本号遵循 语义化版本 2.0.0而 api/version/version.go 中维护着当前 main 分支的版本常量与集群兼容版本// MinClusterVersion is the min cluster version this etcd binary is compatible with. MinClusterVersion 3.0.0 Version 3.8.0-alpha.0当前 main 分支的版本号带有-alpha.0后缀这正是main 是预发布/开发分支这一分支管理策略的直接体现main 上的版本总是下一个 minor 版本的 alpha 预发布直到正式发布被 tag 出去。同一文件中还定义了V3_0到V4_0的完整版本枚举api/version/version.go供集群混合版本mixed-version逻辑使用。二、main 开发分支main分支是 etcd 的开发分支所有新功能new features都首先在这里落地。试验新功能想要尝鲜实验性特性应拉取main分支进行尝试。官方提醒main可能不稳定因为新功能可能引入 bug。Feature freeze功能冻结在下一个稳定版本发布前功能类 PR 会被冻结。会为该 major/minor 版本指派一名发布经理release manager带领 etcd 社区进行为期一到两周的测试、修复与发布文档整理。发布经理团队与具体职责在 Documentation/contributor-guide/release.md 的 Release management 一节有完整说明所有发布版本编号遵循语义化版本 2.0.0major/minor 版本或其预发布发布前需要确认对应 milestone 已完成、升级文档已就绪并在必要时 bump 仓库中硬编码的MinClusterVersion。从 CI 角度看main 分支的绿色构建由 Prow 的 presubmit 任务保障etcd 的 CI 托管在 kubernetes/test-infra 的 Prow 上PR 提交后会自动运行静态检查、单元、集成与 e2e 测试如pull-etcd-e2e-amd64这类任务会针对 main、release-3.6、release-3.5、release-3.4 等分支运行详见 Documentation/contributor-guide/prow_jobs.md。这解释了为什么分支管理规则要求main 必须始终绿色——它是所有稳定分支未来代码的上游。三、稳定分支release- 前缀所有以release-为前缀的分支都被视为稳定分支stable branches例如release-3.4、release-3.5、release-3.6。当前仓库中可观察到从release-0.4到release-3.7的一整排历史稳定分支完整体现了 etcd 自 3.x 时代延续下来的分支命名惯例。稳定分支的生命周期规则每个 minor 版本发布后都会为该版本新建一条稳定分支由**补丁发布经理patch release manager**负责管理社区持续修复最近两个稳定发布中向后兼容的 bug在每个受支持的发布分支上只要存在需要回合的补丁就每两周发布一次 patch 版本。这里的关键约束是只支持最近两个稳定版本当release-3.7与release-3.6同时受支持时release-3.5就不再接收新的 patch 发布。补丁发布的具体门槛在 Documentation/contributor-guide/release.md 的 Patch release criteria 一节给出了量化标准修复了一个或多个重大 CVECVSS ≥ 7.5修复了一个或多个关键 bug修复了三个或更多重要 bug修复了五个或更多次要 bug。满足上述任一条件才值得发布新的 patch 版本配合每两周一次的节奏保证了补丁发布既及时又不泛滥。四、分支是如何诞生的从 main 到新稳定分支branch_management 文档中main 被 tag 后即成为新稳定分支这一句话在仓库的发布流程中对应具体的可执行步骤。4.1 切出稳定分支在 Documentation/contributor-guide/release.md 的 Release steps 第 9 步中写得很明确如果本次是新的 major 或 minor 稳定发布发布完成后通过如下命令创建新的稳定分支git push origin release-${VERSION_MAJOR}.${VERSION_MINOR}也就是说稳定分支不是长期并行开发的而是 main 到达发布点后切分出来的快照之后只接收回合的修复。4.2 发布脚本中的分支语义发布脚本 scripts/release.sh 进一步印证了分支与版本的对应关系if [ -z ${BRANCH:-} ]; then BRANCH$(git rev-parse --abbrev-ref HEAD) else BRANCH${BRANCH:-release-${MINOR_VERSION}} fi脚本从版本号如3.5.13推导出 minor 版本并把默认发布分支解析为release-${MINOR_VERSION}同时脚本会校验 git tag 确实打在${BRANCH}上否则报错终止见 scripts/release.sh。文档中给出的发布命令是# 在仓库根目录执行${VERSION} 为不带 v 前缀的版本号如 3.5.13 DRY_RUNfalse ./scripts/release.sh ${VERSION} # 预发布来自 main 分支的版本如 3.6.0-alpha.2需显式指定 BRANCHmain DRY_RUNfalse BRANCHmain ./scripts/release.sh ${VERSION}注意最后一行预发布alpha/beta/rc从main分支发布而正式 patch 发布从release-X.Y分支发布。这与 api/version/version.go 中 main 分支Version 3.8.0-alpha.0的状态完全吻合——main 产出预发布 tagstable 分支产出正式 tag。仓库构建工具链版本由.go-version当前为 1.26.6约束发布前置条件中也要求本地 Go 版本与该文件保持一致。五、变更如何回移cherry-pick 到稳定分支branch_management 规定向后兼容的 bug 修复先提交到 main随后回合到稳定分支。这个随后回合的机制在 Documentation/contributor-guide/cherry-pick.md 中完整描述有两条路径5.1 自动化路径推荐cherry-pick 主要由k8s-infra-cherrypick-robot处理。在已合并的 PR 下评论目标分支即可/cherry-pick release-3.6机器人会自动创建一个针对目标 release 分支的 cherry-pick PR。注意 release.md 中的约束cherry-pick PR 的提交不应包含 merge commits且内容应严格限定为 bug 修复与安全补丁补丁发布经理会审核这些 PR并从最旧的提交开始按顺序 cherry-pick 到稳定分支保证每个 patch 发布都严格优于其前一个版本。5.2 手动回退路径当自动化机器人不可用时仓库自带了回移脚本 scripts/cherrypick.sh基于 kubernetes 社区的 cherry_pick_pull.sh 改造。先设置远程与环境变量export UPSTREAM_REMOTEupstream # 指向 github.com/etcd-io/etcd 的 remote 名 export FORK_REMOTEorigin # 指向自己 fork 仓库的 remote 名 export GITHUB_USER${github-username}然后将 PR 回移到指定分支并自动发起 PR# 将 PR 12345 cherry-pick 到 release-3.6 并提案为 PR ./scripts/cherrypick.sh ${UPSTREAM_REMOTE}/release-3.6 12345 # 将 12345 和 56789 合并回移作为单个 PR 提案 ./scripts/cherrypick.sh ${UPSTREAM_REMOTE}/release-3.6 12345 56789从源码看scripts/cherrypick.sh脚本要求工作树干净、没有进行中的 rebase/am会校验目标分支是真实存在的远程分支并通过hub工具创建 PR设置DRY_RUN环境变量可跳过 push 和建 PR只把回移的提交留在本地分支中方便制作不打 PR 的补丁。六、对贡献者的实战指引把上述机制落到日常贡献场景可以归纳为一张决策表你要做的事目标分支说明新增功能、API 变更main所有新特性先落地 mainmain 处于 alpha 状态可放心开发修复向后兼容的 bugmain合并后由机器人/经理回合到受支持的release-X.Y请求修复进入稳定版在已合并的 main PR 上评论/cherry-pick release-X.Y仅限 bug 修复与安全补丁不含 merge commit体验最新特性检出main构建可能不稳定不建议生产使用生产环境使用受支持的release-X.Y分支/发布 tag仅最近两个 minor 版本获得 patch 支持几个补充要点feature freeze 期间不要提功能 PR下一个稳定版本发布前一到两周内main 上功能类 PR 冻结只有 bug 修复和文档类变更会被处理此时由该版本的 release manager 主导。stable 分支不做 feature 演进补丁发布经理的职责是维持稳定分支的健康回移内容被严格限制在 bug 修复与安全补丁这与 features 文档中patch 发布不承担 feature 毕业/废弃的规则见 Documentation/contributor-guide/features.md一致。版本联动稳定分支的发布还会触发下游联动——例如 etcd 3.6 补丁需要 bump 到 Kubernetes 1.34 及更新版本3.5 补丁 bump 到 Kubernetes 1.33 及更早受支持版本流程见 Documentation/contributor-guide/bump_etcd_version_k8s.md。这说明 etcd 的分支体系不是孤立的而是与整个 Kubernetes 生态的发布节奏耦合在一起的。七、小结etcd 的分支管理可以浓缩为三条主线main 负责演进新功能、alpha 预发布、feature freeze 管理、release-X.Y 负责稳定每两周一次的 patch 节奏、只支持最近两个 minor 版本、严格限制回移内容、cherry-pick 负责两者之间的桥接机器人自动化优先scripts/cherrypick.sh 手动兜底。理解这套模型后无论是提交 PR、参与发布还是排查版本兼容性都能准确地把变更放到正确的分支上。【免费下载链接】etcdDistributed reliable key-value store for the most critical data of a distributed system项目地址: https://gitcode.com/GitHub_Trending/et/etcd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
