版本发布流程[DRAFT]

基于 GitHub Action 提供的自动化服务，简化发布流程及成本。基本上包含四种版本发布流程

• 用于 Pull Request 的测试版本，在 Pull Request 中评论 /publish 后自动发布，权限要求为仓库 OWNER 或 MEMBER，发布 npm tag 为 alpha
• 用于正式版本发布前的验证版本(Pre-release)，由 MEMBER 或 OWNER 根据 Pre-release issue 模板创建，后续可以在 issue 中评论 /pre-release 发布，发布 npm tag 为 next
• 用于正式版本发布，由 MEMBER 或 OWNER 根据 Pre-release issue 模板创建，在 issue 中评论 /release 后发布，发布 npm tag 为 latest
• hotfix 版本发布，签出对应 release 版本分支，名为 vx.x，在 release 分支提交 Pull Request // TODO

详细流程

Pull Request 测试版本发布如上述流程。

Pre-release 验证版本流程

1. 由 OWNER 或 MEMBER 基于 Pre-release 模板创建 issue，无需修改 issue 内容，新建即可
2. 新建 issue 后会自动发布 next 版本，同时会做以下几件事
   1. 获取该版本 CHANGELOG 并更新到 issue 正文，参考 🤖 OpenSumi Pre-release Thu Dec 30 2021
   2. 修改标题为 🤖 OpenSumi Pre-release <当日日期>
3. 轮值人员验证版本后如有新的 bug ，创建 issue 并添加 pre-release、bug 标签
4. 将 bug issue 添加到 Pre-release issue bug 评论区，类似这个
5. 相关 bugfix 的 Pull Request 需关联到 bug issue，合入后自动关闭

所有问题修复后，Pre-release 流程结束，关闭 issue ，发布正式版本

正式版本流程

1. 由版本轮值人员修改 lerna.json 为新的版本号，并 push 到 main 分支
2. 基于 Release 模板创建 issue，无需修改 issue 内容，新建即可
3. 版本轮值人员在 issue 中评论 /release 后自动发布
4. 发布正式版本会做以下几件事
   1. 添加 tag 并 push 到 main 分支
   2. 发布 GitHub Release
   3. 生成 CHANGELOG 并更新到 release issue 正文
   4. 关闭并锁定 issue