Skip to main content
版本: 0.4.4

KCL 发布策略

开发团队希望采用 语义化版本 来简化管理。版本格式:主版本号.次版本号.修订号。版本号递增规则如下:主版本号对应不兼容的 API 修改,次版本号对应向下兼容的功能性新增,修订号对应向下兼容的问题修正。其中主版本号和次版本号均包含了不一样的特性统一称之为大版本,补丁修复称之为小版本。

总体目标是每个季度发布一个特性增强的大版本,并支持最近发布的两个大版本,根据需要不定期发布其他版本的修订。

1. 发布流程

发布流程如下:

  • main 主干开发,每日产出一个 Nightly 版本,CI 系统进行测试
  • beta 测试分支,经过 6 周后从 Nightly 版本产出一个 Beta 版本
  • stable 稳定分支,经过 6 周后从 Beta 版本产出一个 Stable 版本
  • release-branch.kcl-x.y 发布分支,每个季度从 Stable 版本产出一个 rc 候选版本,并最终发布
  • release-branch.kcl-x.y 分支的 BUG 修复需要合并回 main,然后逐步同步到 beta、stable 分支

其中 stable、beta 只是延迟的 main 分支,release-branch.kcl-x.y 发布后将和 main 保存独立。

如果本次发布失败,则顺延到下个发布周期。

2. 发布维护

发布次要版本以解决一个或多个没有解决方法的关键问题(通常与稳定性或安全性有关)。版本中包含的唯一代码更改是针对特定关键问题的修复。重要的仅文档更改和安全测试更新也可能包括在内,但仅此而已。一旦 KCL 1.x+2 发布,解决 KCL 1.x 的非安全问题的次要版本就会停止更新。解决 KCL 1.x 安全问题的次要版本在 KCL 1.x+2 发布后停止。