Skip to content

Latest commit

 

History

History
43 lines (30 loc) · 2.91 KB

MAINTAINING-CH.md

File metadata and controls

43 lines (30 loc) · 2.91 KB

Maintaining

项目管理

Davinci 项目通过 Project 来管理开发计划和维护清单。

开发计划

开发计划在 Roadmap 中管理。Committers 可以在 To do 栏中自行添加功能卡片,当功能还在卡片阶段时,意味着此功能还在设计和讨论阶段,卡片中应当包含:

  • 功能描述标题
  • 功能设计明细及原理
  • 如果包含子功能项,请逐一列出

当功能经过设计和讨论阶段之后,可以将功能卡片转成 Issue,并打上相应的 Tags。如果有 Committers 计划开发实现它,请将 Issue 拖到 In progress 栏中,并添加自己到 Issue 的 Assignees 列表中。请确保功能经过充分设计和讨论之后再开始开发,未经社区讨论过的功能 PR 不会被合并。

维护清单

维护清单在 Maintenance 中管理。Committers 可以在 To do 栏中自行添加 bug 或亟待修复的缺陷类 Issue。同样的,如果有 Committers 计划开发修复它,请将 Issue 拖到 In progress 栏中,并添加自己到 Issue 的 Assignees 列表中。

为保证开发高效以及目标专注,建议每位 Committer 在所有 Project In progress 栏中的 Issue 不超过2个。

版本发布周期及流程

当前阶段,如无特殊需求,每月发布一个 minor 版本,正式版本发布不遵循此规则

版本发布之前需要确认

  • 所有功能可以正常运行
  • 与此版本相关的 Issue 和 PR 已经被正确处理

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

  • 新建一个 PR 将 dev-0.3 分支合并到 master,所有发布操作需要在 master 分支上进行。注意!不要使用 squash merge!防止提交信息丢失!
  • 从 master 新建一个 release 分支用来做发布的修改(例如:git checkout -b release-beta.7)
  • 在 CHANGELOG.md 里添加发布日志,可以用 compare 功能找到当前和之前版本的区别,将有价值的改动如实反馈给用户
  • 对用户使用上无感知的改动建议(文档修补、微小的样式优化、代码风格重构等等)不要提及,保持 changelog 的内容有效性
  • 用面向开发者的角度和叙述方式撰写 changelog,不描述修复细节,描述问题和对开发者的影响
  • 尽量给出原始的 PR 链接,社区提交的 PR 改动加上提交者的链接或 Issue 链接
  • 如果不确定改动的真实目的,可以向提交者进行咨询
  • push release 分支并发起 changelog 的 PR 请其他 Committee 成员进行 Review
  • PR 的内容里填上 changelog 内容,好处是版本 changelog 的 PR 会关联在各个 issue 中,很容易知道 Issue 在哪个版本被改了

正式发布 release

  • 更新日志的修改合并后,删除 release-x 分支,给当前 master 分支打上版本号 tag
  • 上传 release 包,发布 release note