轮值规则

  1. 如无特殊需求，每周五发布一个 patch 版本，也可按照具体改动判断是否发布 minor 版本。major 版本发布不遵循此规则。
  2. 发布进行按周轮值。
  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 用于使用相关的提问，机器人会自动回复。

☎️ 注意！

在 4.0 版本发布前，轮值同学需要将 master 合并入 4.0-prepare 分支。
**

发布流程

1. 发布前相关工作

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

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

  • 如果是发布 minor 版本，先新建一个 pr 将 feature 分支合并到 master，所有发布操作需要在 master 分支上进行。注意！不要使用 squash merge！防止提交信息丢失！
  • 从 master 新建一个 release 分支用来做发布的修改（例如：git checkout -b release-3.6.0）。
  • 在 CHANGELOG.en-US.md 和 CHANGELOG.zh-CN.md 和 里添加发布日志，可以用 compare 功能找到当前和之前版本的区别，将有价值的改动如实反馈给用户。
  • 对用户使用上无感知的改动建议（文档修补、微小的样式优化、代码风格重构等等）不要提及，保持 CHANGELOG 的内容有效性。
  • 用面向开发者的角度和叙述方式撰写 CHANGELOG，不描述修复细节，描述问题和对开发者的影响。格式可以参考以往的 changelog。
  • 新增属性时，建议用易于理解的语言描述用户可以感知的变化。（例如，新增 onCellClick 属性，可以定义单元格点击事件）
  • 尽量给出原始的 PR 链接，社区提交的 PR 改动加上提交者的链接。
  • 底层模块升级中间版本要去 rc-component 里找到改动，给出变动说明。
  • 如果不确定改动的真实目的，可以向提交者进行咨询。
  • 参考之前版本的日志写法，添加必要的截图帮助说清楚新功能。
  • 每一个改动前加一个 emoji 增加文档的可读性和生动性，可选的 emoji 参考这里。
  • push release 分支并发起 CHANGELOG 的 PR 请其他同学 review。
  • PR 的主楼内容里直接复制上 CHANGELOG 的改动内容，好处是版本 CHANGELOG 的 PR 会关联在各个 issue 中，很容易知道 issue 在哪个版本被改了。https://github.com/ant-design/ant-design/pull/15018

changelog PR 可以参考 https://github.com/ant-design/ant-design/pull/12615 。

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

3. npm 发布

更新日志的修改合并后，删除 release-x.x.x 分支。接下来可以正式发布 antd。

  • 执行 rm -rf node_modules && npm i，如果有.lock 文件，最好删除后进行安装，确保 node_modules 目录是最新的。
  • 按照语义化版本修改版本号，bugfix 升级小版本，新功能添加升级中间的版本号。
  • 在项目根目录下执行：npm run pub

检查 releases 和 unpkg 是否发布成功。

4. 发布网站（已经使用 github action 自动化）

文档发布已经自动化，此处仅做留档。

  1. $ npm run deploy
  2. $ npm run deploy:china-mirror

依次执行完上面的两条命令后，访问 https://ant.design 和国内站点 https://ant-design.gitee.io 确认网站发布成功。

6. 更新 feature 分支

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

changelog 规范

优先使用 Emoji，其次为 Angular changelog

Emoji for changelog

  • 🐞 Bug 修复
  • 💄 样式更新/less 变量更新
  • 🆕 新增特性
  • 🔥 极其值得关注的新增特性
  • 🇺🇸🇨🇳🇬🇧 国际化改动，注意这里直接用对应国家/地区的旗帜。
  • 📖 文档或网站改进
  • ✅ 新增或更新测试用例
  • 🛎 更新警告/提示信息
  • ⌨️ 可访问性增强
  • 🗑 废弃或移除
  • 🛠 重构或工具链优化
  • ⚡️ 性能提升

Angular Git changelog

  1. <type>(<scope>): <subject>
  2. <BLANK LINE>
  3. <body>
  4. <BLANK LINE>
  5. <footer>

我们通过 git commit 命令带出的 vim 界面填写的最终结果应该类似如上这个结构, 大致分为三个部分(使用空行分割)：

  • 标题行: 必填, 描述主要修改类型和内容。
  • 主题内容: 描述为什么修改, 做了什么样的修改, 以及开发的思路等等。
  • 页脚注释: 放 Breaking Changes 或 Closed Issues。

分别由如下部分构成：

  • type: commit 的类型
  • feat: 新特性
  • fix: 修改问题
  • refactor: 代码重构
  • docs: 文档修改
  • style: 代码格式修改, 注意不是 css 修改
  • test: 测试用例修改
  • chore: 其他修改, 比如构建流程, 依赖管理.
  • scope: commit 影响的范围, 比如: route, component, utils, build…
  • subject: commit 的概述, 建议符合 50/72 formatting
  • body: commit 具体修改内容, 可以分为多行, 建议符合 50/72 formatting
  • footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.

这样一个符合规范的 commit message，就好像是一份邮件。