轮值规则和版本发布流程

偏右 edited this page Jun 4, 2018 · 44 revisions

轮值规则

  1. 如无特殊需求,每周五发布一个 patch 版本,也可按照具体改动判断是否发布 minor 版本。major 版本发布不遵循此规则。
  2. 从 2016 年 5 月 14 日起,发布进行按周轮值
  3. 轮值人当周负责
    • 及时进行 PR Reveiew 的分配和合并操作。(不要合并 In Progress WIP 的 PR)
    • 定位、分配、跟踪需要解决的 Issue。
    • 关闭已解决或无法解决的 Issue。
    • 按时进行新版本发布。
  4. 标签的使用
    • good first issue 用于比较简单的 issue,鼓励社区的贡献。
    • Component: [name] 用于特定组件相关的 issue,机器人会自动 assign 给 owner。
    • Need Reproduce 用于没有提供重现的 issue,机器人会自动回复,如果之后 7 天都没有再回复,机器人会自动关闭 issue。
    • Usage 用于使用相关的提问,机器人会自动回复。

团队

你可以分配 issue 和 pull request 的用户包括:

  • 核心团队:@yiminghe @yesmeck @RaoHai @ddcat1115 @benjycui @afc163 @nikogu
  • 社区成员:@bang88 @infeng @GrayChoi @xueqingxiao
  • 设计师:@chinglik @yingxirz

发布流程

1. 发布前相关工作。

  • 确认 Travis CI 是绿的。
  • 并且一些简单明确的 issue 和 PR 已被处理和合并。
  • 如果是发布 minor 版本,依赖的 rc 组件版本在向下兼容的前提下升级到最新(参看 david 版本过期服务),升级后对演示进行基本的人工检查。

2. 编辑更新日志以及升级版本号

  • 如果是发布 minor 版本,先把 feature 分支手工合并到 master。
  • 从 master 新建一个 release 分支用来做发布的修改(例如:git checkout -b release-3.6.0)。
  • 在 CHANGELOG.md 里添加发布日志,可以用 compare 功能找到当前和之前版本的区别,将有价值的改动如实反馈给用户。
  • 对用户使用上无感知的改动建议(文档修补、微小的样式优化、代码风格重构等等)不要提及,保持 changelog 的内容有效性。
  • 用面向开发者的角度和叙述方式撰写 CHANGELOG,不描述修复细节,描述问题和对开发者的影响。
  • 新增属性时,建议用易于理解的语言描述用户可以感知的变化。(例如,新增 onCellClick 属性,可以定义单元格点击事件)
  • 尽量给出原始的 issue 或 PR 链接,社区提交的 PR 改动加上提交者的链接。
  • 底层模块升级中间版本要给出变动说明。
  • 如果不确定改动的真实目的,可以向提交者进行咨询。
  • 参考之前版本的日志写法,添加必要的截图帮助说清楚新功能。
  • push release 分支并发起 PR 请其他同学 review。

注:底层 rc 组件的小版本修复,可以不用写入 changelog。

2. npm 发布

更新日志的修改合并后,可以正式发布 antd

  • 执行 rm -rf node_modules && npm i,确保 node_modules 目录是最新的。
  • 按照语义化版本修改版本号,bugfix 升级小版本,新功能添加升级中间的版本号。
  • 在项目根目录下执行:
npm run pub

4. 发布网站

npm run deploy
  • 执行完上面的命令后,整个发布过程结束。

5. 更新 feature 分支

发版确认一切正常后,应及时合并 master 进当前的 feature 分支。

如果是发布 minor 版本,则需要删除旧的 feature-x.x 分支,并 checkout 出下一个 feature-x.x 分支。