Skip to content

Latest commit

 

History

History
105 lines (61 loc) · 5.77 KB

版本发布管理.md

File metadata and controls

105 lines (61 loc) · 5.77 KB

背景

本文档规范了 Venus 项目团队内部发版流程，与社区同步最新 Venus 组件相关版本。部分流程参考了 Lotus 的 release_flow。

版本号概述

以版本号格式 vX.Y.Z(如：v1.6.0，等等)为例：

  • 主版本（Major Release）（X 版本，如：v1.0.0，v2.0.0，等等）代表重大 filecoin 协议升级，例如，vm，封装算法等。自 filecoin1.0 以来，至 nv16 ，暂时还没有 X 号升级。
  • 次版本（Minor Release）（Y 版本，如：v1.10.0，v1.11.0等等）代表打网络破共识的升级，为强制网络升级。
  • 修订 hotfix 版本（Hotfix Release）（Y 版本的hotfix的 Z+1 版本，如：v1.10.1，v1.10.2，v1.11.1，等等）针对 Y 版本修复bug的版本，发布对应双数 Y 版本的 Z+1 版本。即，默认主网环境社区需要使用最新 Y 版本对应的最新 Z 版本。
  • Venus 团队将1到2个 sprint 对各个组件发布 feature 版本的 Y 版本。主网升级期间，这个规律可能会被打破。
  • 针对网络 nv 升级，发版惯例为，butterfly 网络对应 vX.Y.Z-pre-rc[x] 版本，calibration 网络对应 vX.Y.Z-rc[x] 版本。

版本号分支开发

以版本号为基础的分支开发规范，请参阅分支管理规范和分支保护规则。

版本发布流程

  • 使用 Venus 发版模版，由 tpm 或者研发发起下个版本发布的 issue。（模版参考了 Lotus 的issue模版）
  • 研发基于上述版本号创建开发分支，进行开发。提交 PR 至开发分支，后续把开发分支合并到 master 分支，待代码冻结后从 master 切出 release 分支用于发布版本。
  • 按照发版 issue 中定义的自测，社区测试，最终发版等流程执行发版。
  • 在 Slack 社区的 #fil-venus-announcement 频道中，进行官宣。
  • 每个主/次版本（X or Y版本）升级上线后的第二个工作日，进行下一个milestone功能集的选择会议。
  • 每次Sprint总结会选择下一个Sprint主题时，首先根据milestone来选择，Sprint主题和milestone需要保持同步更新。
  • 重复该流程。

分支

分支定义为：master、开发分支、release 分支及普通分支。普通分支为开发者自己创建的分支，最终必然会合并到其他类分支。

开发分支

一个版本创建一个开发分支，格式：dev/vX.Y，例：dev/v1.8。

创建开发分支

根据 milestones 的计划来创建开发分支，开发分支从当前 master 切出来。这就意味着开发分支可以有多个，每个开发分支代表一个版本，有助于做长期规划，将 issue 提前预设到版本对应的 milestone。

master 的 commit 并入开发分支

当合并到主分支的 pr 在开发分支也需要时，用 rebase 或者 cherry-pick 的方式合并到开发分支。

解决开发分支与 master 冲突

若开发分支可以强推（git push -f），则可以通过 rebase 的方式解决冲突，若不可以强推则通过 merge master 的方式来解决冲突。

开发分支合入 master

  1. 待上一个版本的稳定版本发布后(打了 tag)，当前版本开发分支合入 master。
  2. 后续本版本的 pr 都往 master 合并。

一个 pr 需要合并到多个开发分支

把该 pr 合并到一个开发分支，然后通过 cherry-pick 方式把该 pr 合并到其它的开发分支。

release 分支

release 分支指形如 release/vX.Y 的分支，用于发布版本。

一个版本只建一个 release 分支，v1.8.x 版本只会建 release/v1.8 分支，不会在发布版本 v1.8.1 时建 release/v1.8.1 分支，v1.8.1 版本的修改都合入到 release/v1.8 分支，并从 release/v1.8 分支发布版本。

创建 release 分支

基于 master 分支创建，创建时应符合以下条件：

  • 当前版本代码冻结，不再加入新的 feature。
  • 版本升级相关的 pr （如：升级版本及changlog）均先合并到 master。

非网络升级

发布 rc 后需要修改，先把代码合入到 master，再 cherry-pick 到 release 分支。

网络升级

venus 发布 rc 后到正式版本之间会有一段较长时间，期间可能会有较多修改，为了减少工作量，统一把代码合入到 release 分支。 venus 按下面规则，非 venus 按非网络升级的规则。

  • 发布 rc 后需要修改，把代码都合入到 release 分支。
  • 发布第一个稳定版本后需要把代码合入到 master。
  • 发布稳定版本后需要修改，先把代码合入到 master，再 cherry-pick 到 release 分支。

版本发布

rc 版本、稳定版本和bug 修复版本都从 release 分支发布版本。

rc 版本

创建 release 分支时已更新版本号和 CHANGELOG，可以直接发 vX.Y.X-rc[x] 版本（x = 1, 2, 3...）。

稳定版本

从 release 分支打 Tag，涉及的 pr 均合并到 release 分支。

  • 更新版本号和 CHANGELOG。
  • 发布版本，即从 release 分支打 Tag。

bug 修复版本

  • 先把修复 pr 合入 master，再 cherry-pick 到 release 分支。
  • 更新版本号和 CHANGELOG。
  • 发布版本，即从 release 分支打 Tag。