KCL Release Policy

KCL 开发团队采用 语义化版本 来简化管理。版本格式：主版本号.次版本号.修订号。版本号递增规则如下：主版本号对应不兼容的 API 修改，次版本号对应向下兼容的功能性新增，修订号对应向下兼容的问题修正。总体目标是每一个半月发布一个特性增强的次要版本，根据需要不定期发布其他版本的修订。

KCL 项目版本发布策略如下：

• 主版本号：当进行重大的架构调整或者加入重大的新功能时，需要提升主版本号。对于 KCL 项目来说，目前的主版本号为 0。
• 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 5，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
• 修订号：通过修复漏洞或者改进性能来更新程序时，会提升修订号，修订号从 0 开始计数以此加 1。
• 发布周期：在未达到 v1.0.0 版本之前，计划每隔 3 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
• 发布流程：在发布新版本之前，需要进行严格的测试和审核，确保新版本的质量。封板并测试完成后，会在 Github 上发布新版本的源代码，二进制和镜像，并提供详细的文档和使用指南。
• 版本支持：我们将对最新的版本提供长期支持，包括漏洞修复和安全更新。对于旧版本，我们将提供有限的支持，仅在必要时进行修复。

发布流程与规则

• 特性开发：main 分支主干开发，分支发布，block 用户使用的问题和严重的 bug, 安全隐患，高优先级解决，尽可能保持在一周内收敛，高于一般的功能研发。
• 迭代周期：我们的迭代周期通常为 3 个月，即每 3 个月发布一个新的次要版本。
• 版本规划：发版前两周产出 alpha 版本，前一周产出 beta 版本，alpha 版本仍可进行特性合并，beta 版本只合并错误修复，最终产出正式版本并打 tag 作为长期保存的 release 分支。
• 发版计划：在每个发布周期开始时制定详细的发版计划（Github Milestone），包括发布日期、版本号、功能列表和测试计划等。需要尽可能地遵守发版计划，确保按时发布新版本。
• 发布前测试：在发布新版本之前，需要进行全面的测试，包括单元测试、集成测试，模糊测试，压测，用户验收测试等。只有经过测试并无问题后，我们才会发布新版本。
• 版本回滚：如果在发布后发现了严重的问题，需要立即回滚版本，并尽快修复问题。并通过邮件、社交媒体等渠道及时通知用户，并提供解决方案。
• 发布文档：需要在发布时提供详细的文档，包括发布说明、更新日志、API 文档和使用指南等，帮助用户了解和使用新版本。在 KCL 中，我们统一在 KCL 网站进行维护。
• 版本兼容性：在发布新版本时，需要尽可能保持兼容性，以确保用户无需进行过多的修改和适应。KCL 还没有达到 v1，暂时没有兼容性保证。KCL 的目标是尽可能少地进行重大更改，不应轻率地考虑对语言的更改，为了语言自身更好地演进和发展，一般认为更改具有重大好处时才会进行（较好地解决了目标场景的问题或者提升了绝大用户的使用体验）。对于可能引入兼容性问题的功能或变更，提供相应的提示和解决方案，同时会提供逐步升级的指南或提供自动迁移的工具，以帮助用户平滑地迁移到新版本。

发布组件

每次版本发布时，KCL 相关所有组件保持一个依赖同一个 KCL 核心主要版本，整体采用树形结构组织依赖顺序发布并进行回归测试，直到发布测试完成，尽力避免三角依赖，禁止循环依赖。

一个 Feature 的生命周期

• 设计方案/文档：通过 Issue 回答清楚这个 feature 的动机是什么，它解决什么问题以及目标是什么，用户需求和用户故事是怎样的；这个 feature 做什么，如何做，难度怎样，需要多长时间，依赖项，需要做什么测试等。(Tips: 大的设计尽量拆分成小的设计，通过权衡和广泛的调研找到一个简单且可持续的解决方案，并且具备一定得到可扩展以适应未来的业务或技术变化，通过持续讨论和方案评审确定最终设计)。
• 编写代码：通过高频小改动进行迭代、持续沟通和协作，提前设计单元测试、集成测试和 benchmark 等测试用例，确保编写代码 100% 测试覆盖，注释完整和逻辑清晰，并通过 Demo 演示持续收集反馈。
• 文档撰写：在 KCL 网站 中更新用户文档。
• 测试和反馈：在发布功能之前，让一些同行/用户通过随循文档而不是口述来尝试和测试这些新功能。接收反馈并改进。
• 发布和公告：撰写 Release Note, PR 文章，场景和新特性解读等以及渠道宣发等。

注：以上所有信息全是公开的，需要透出给所有社区研发者进行参与、讨论和贡献。