refactor: refine release policy version and cycle

Author: Peefy

docs/community/release-policy/kcl.md

@@ -5,16 +5,16 @@ KCL 开发团队采用 [语义化版本](https://semver.org/lang/zh-CN/) 来简
 KCL 项目版本发布策略如下：
 
 + 主版本号：当进行重大的架构调整或者加入重大的新功能时，需要提升主版本号。对于 KCL 项目来说，目前的主版本号为 0。
-+ 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 4，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
++ 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 5，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
 + 修订号：通过修复漏洞或者改进性能来更新程序时，会提升修订号，修订号从 0 开始计数以此加 1。
-+ 发布周期：在未达到 v1.0.0 版本之前，计划每隔 1.5 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
++ 发布周期：在未达到 v1.0.0 版本之前，计划每隔 3 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
 + 发布流程：在发布新版本之前，需要进行严格的测试和审核，确保新版本的质量。封板并测试完成后，会在 Github 上发布新版本的源代码，二进制和镜像，并提供详细的文档和使用指南。
 + 版本支持：我们将对最新的版本提供长期支持，包括漏洞修复和安全更新。对于旧版本，我们将提供有限的支持，仅在必要时进行修复。
 
 ## 发布流程与规则
 
 + 特性开发：main 分支主干开发，分支发布，block 用户使用的问题和严重的 bug, 安全隐患，高优先级解决，尽可能保持在一周内收敛，高于一般的功能研发。
-+ 迭代周期：我们的迭代周期通常为 1.5 个月，即每 1.5 个月发布一个新版本。
++ 迭代周期：我们的迭代周期通常为 3 个月，即每 3 个月发布一个新的次要版本。
 + 版本规划：发版前两周产出 alpha 版本，前一周产出 beta 版本，alpha 版本仍可进行特性合并，beta 版本只合并错误修复，最终产出正式版本并打 tag 作为长期保存的 release 分支。
 + 发版计划：在每个发布周期开始时制定详细的发版计划（Github Milestone），包括发布日期、版本号、功能列表和测试计划等。需要尽可能地遵守发版计划，确保按时发布新版本。
 + 发布前测试：在发布新版本之前，需要进行全面的测试，包括单元测试、集成测试，模糊测试，压测，用户验收测试等。只有经过测试并无问题后，我们才会发布新版本。
@@ -32,8 +32,8 @@ KCL 项目版本发布策略如下：
 
 + 设计方案/文档：通过 Issue 回答清楚这个 feature 的动机是什么，它解决什么问题以及目标是什么，用户需求和用户故事是怎样的；这个 feature 做什么，如何做，难度怎样，需要多长时间，依赖项，需要做什么测试等。(Tips: 大的设计尽量拆分成小的设计，通过权衡和广泛的调研找到一个简单且可持续的解决方案，并且具备一定得到可扩展以适应未来的业务或技术变化，通过持续讨论和方案评审确定最终设计)。
 + 编写代码：通过高频小改动进行迭代、持续沟通和协作，提前设计单元测试、集成测试和 benchmark 等测试用例，确保编写代码 100% 测试覆盖，注释完整和逻辑清晰，并通过 Demo 演示持续收集反馈。
-+ 文档撰写：在 kcl-lang.io 中更新用户文档。
-+ 测试和反馈：在发布功能之前，让一些同行/用户通过随循文档来尝试和测试这些新功能。接收反馈并改进。
++ 文档撰写：在 [KCL 网站](https://kcl-lang.io) 中更新用户文档。
++ 测试和反馈：在发布功能之前，让一些同行/用户通过**随循文档**而不是口述来尝试和测试这些新功能。接收反馈并改进。
 + 发布和公告：撰写 Release Note, PR 文章，场景和新特性解读等以及渠道宣发等。
 
 > 注：以上所有信息全是公开的，需要透出给所有社区研发者进行参与、讨论和贡献。

i18n/zh-CN/docusaurus-plugin-content-docs/current/community/release-policy/kcl.md

@@ -1,20 +1,20 @@
-# KCL 发布策略
+# KCL Release Policy
 
 KCL 开发团队采用 [语义化版本](https://semver.org/lang/zh-CN/) 来简化管理。版本格式：主版本号.次版本号.修订号。版本号递增规则如下：主版本号对应不兼容的 API 修改，次版本号对应向下兼容的功能性新增，修订号对应向下兼容的问题修正。总体目标是每一个半月发布一个特性增强的次要版本，根据需要不定期发布其他版本的修订。
 
 KCL 项目版本发布策略如下：
 
 + 主版本号：当进行重大的架构调整或者加入重大的新功能时，需要提升主版本号。对于 KCL 项目来说，目前的主版本号为 0。
-+ 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 4，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
++ 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 5，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
 + 修订号：通过修复漏洞或者改进性能来更新程序时，会提升修订号，修订号从 0 开始计数以此加 1。
-+ 发布周期：在未达到 v1.0.0 版本之前，计划每隔 1.5 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
++ 发布周期：在未达到 v1.0.0 版本之前，计划每隔 3 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
 + 发布流程：在发布新版本之前，需要进行严格的测试和审核，确保新版本的质量。封板并测试完成后，会在 Github 上发布新版本的源代码，二进制和镜像，并提供详细的文档和使用指南。
 + 版本支持：我们将对最新的版本提供长期支持，包括漏洞修复和安全更新。对于旧版本，我们将提供有限的支持，仅在必要时进行修复。
 
 ## 发布流程与规则
 
 + 特性开发：main 分支主干开发，分支发布，block 用户使用的问题和严重的 bug, 安全隐患，高优先级解决，尽可能保持在一周内收敛，高于一般的功能研发。
-+ 迭代周期：我们的迭代周期通常为 1.5 个月，即每 1.5 个月发布一个新版本。
++ 迭代周期：我们的迭代周期通常为 3 个月，即每 3 个月发布一个新的次要版本。
 + 版本规划：发版前两周产出 alpha 版本，前一周产出 beta 版本，alpha 版本仍可进行特性合并，beta 版本只合并错误修复，最终产出正式版本并打 tag 作为长期保存的 release 分支。
 + 发版计划：在每个发布周期开始时制定详细的发版计划（Github Milestone），包括发布日期、版本号、功能列表和测试计划等。需要尽可能地遵守发版计划，确保按时发布新版本。
 + 发布前测试：在发布新版本之前，需要进行全面的测试，包括单元测试、集成测试，模糊测试，压测，用户验收测试等。只有经过测试并无问题后，我们才会发布新版本。
@@ -32,8 +32,8 @@ KCL 项目版本发布策略如下：
 
 + 设计方案/文档：通过 Issue 回答清楚这个 feature 的动机是什么，它解决什么问题以及目标是什么，用户需求和用户故事是怎样的；这个 feature 做什么，如何做，难度怎样，需要多长时间，依赖项，需要做什么测试等。(Tips: 大的设计尽量拆分成小的设计，通过权衡和广泛的调研找到一个简单且可持续的解决方案，并且具备一定得到可扩展以适应未来的业务或技术变化，通过持续讨论和方案评审确定最终设计)。
 + 编写代码：通过高频小改动进行迭代、持续沟通和协作，提前设计单元测试、集成测试和 benchmark 等测试用例，确保编写代码 100% 测试覆盖，注释完整和逻辑清晰，并通过 Demo 演示持续收集反馈。
-+ 文档撰写：在 kcl-lang.io 中更新用户文档。
-+ 测试和反馈：在发布功能之前，让一些同行/用户通过随循文档来尝试和测试这些新功能。接收反馈并改进。
++ 文档撰写：在 [KCL 网站](https://kcl-lang.io) 中更新用户文档。
++ 测试和反馈：在发布功能之前，让一些同行/用户通过**随循文档**而不是口述来尝试和测试这些新功能。接收反馈并改进。
 + 发布和公告：撰写 Release Note, PR 文章，场景和新特性解读等以及渠道宣发等。
 
 > 注：以上所有信息全是公开的，需要透出给所有社区研发者进行参与、讨论和贡献。

i18n/zh-CN/docusaurus-plugin-content-docs/version-0.5.0/community/release-policy/kcl.md

@@ -1,20 +1,20 @@
-# KCL 发布策略
+# KCL Release Policy
 
 KCL 开发团队采用 [语义化版本](https://semver.org/lang/zh-CN/) 来简化管理。版本格式：主版本号.次版本号.修订号。版本号递增规则如下：主版本号对应不兼容的 API 修改，次版本号对应向下兼容的功能性新增，修订号对应向下兼容的问题修正。总体目标是每一个半月发布一个特性增强的次要版本，根据需要不定期发布其他版本的修订。
 
 KCL 项目版本发布策略如下：
 
 + 主版本号：当进行重大的架构调整或者加入重大的新功能时，需要提升主版本号。对于 KCL 项目来说，目前的主版本号为 0。
-+ 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 4，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
++ 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 5，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
 + 修订号：通过修复漏洞或者改进性能来更新程序时，会提升修订号，修订号从 0 开始计数以此加 1。
-+ 发布周期：在未达到 v1.0.0 版本之前，计划每隔 1.5 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
++ 发布周期：在未达到 v1.0.0 版本之前，计划每隔 3 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
 + 发布流程：在发布新版本之前，需要进行严格的测试和审核，确保新版本的质量。封板并测试完成后，会在 Github 上发布新版本的源代码，二进制和镜像，并提供详细的文档和使用指南。
 + 版本支持：我们将对最新的版本提供长期支持，包括漏洞修复和安全更新。对于旧版本，我们将提供有限的支持，仅在必要时进行修复。
 
 ## 发布流程与规则
 
 + 特性开发：main 分支主干开发，分支发布，block 用户使用的问题和严重的 bug, 安全隐患，高优先级解决，尽可能保持在一周内收敛，高于一般的功能研发。
-+ 迭代周期：我们的迭代周期通常为 1.5 个月，即每 1.5 个月发布一个新版本。
++ 迭代周期：我们的迭代周期通常为 3 个月，即每 3 个月发布一个新的次要版本。
 + 版本规划：发版前两周产出 alpha 版本，前一周产出 beta 版本，alpha 版本仍可进行特性合并，beta 版本只合并错误修复，最终产出正式版本并打 tag 作为长期保存的 release 分支。
 + 发版计划：在每个发布周期开始时制定详细的发版计划（Github Milestone），包括发布日期、版本号、功能列表和测试计划等。需要尽可能地遵守发版计划，确保按时发布新版本。
 + 发布前测试：在发布新版本之前，需要进行全面的测试，包括单元测试、集成测试，模糊测试，压测，用户验收测试等。只有经过测试并无问题后，我们才会发布新版本。
@@ -32,8 +32,8 @@ KCL 项目版本发布策略如下：
 
 + 设计方案/文档：通过 Issue 回答清楚这个 feature 的动机是什么，它解决什么问题以及目标是什么，用户需求和用户故事是怎样的；这个 feature 做什么，如何做，难度怎样，需要多长时间，依赖项，需要做什么测试等。(Tips: 大的设计尽量拆分成小的设计，通过权衡和广泛的调研找到一个简单且可持续的解决方案，并且具备一定得到可扩展以适应未来的业务或技术变化，通过持续讨论和方案评审确定最终设计)。
 + 编写代码：通过高频小改动进行迭代、持续沟通和协作，提前设计单元测试、集成测试和 benchmark 等测试用例，确保编写代码 100% 测试覆盖，注释完整和逻辑清晰，并通过 Demo 演示持续收集反馈。
-+ 文档撰写：在 kcl-lang.io 中更新用户文档。
-+ 测试和反馈：在发布功能之前，让一些同行/用户通过随循文档来尝试和测试这些新功能。接收反馈并改进。
++ 文档撰写：在 [KCL 网站](https://kcl-lang.io) 中更新用户文档。
++ 测试和反馈：在发布功能之前，让一些同行/用户通过**随循文档**而不是口述来尝试和测试这些新功能。接收反馈并改进。
 + 发布和公告：撰写 Release Note, PR 文章，场景和新特性解读等以及渠道宣发等。
 
 > 注：以上所有信息全是公开的，需要透出给所有社区研发者进行参与、讨论和贡献。

versioned_docs/version-0.5.0/community/release-policy/kcl.md

@@ -5,16 +5,16 @@ KCL 开发团队采用 [语义化版本](https://semver.org/lang/zh-CN/) 来简
 KCL 项目版本发布策略如下：
 
 + 主版本号：当进行重大的架构调整或者加入重大的新功能时，需要提升主版本号。对于 KCL 项目来说，目前的主版本号为 0。
-+ 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 4，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
++ 次版本号：当添加的功能和特性有较大的变化时，提升次版本号。目前的次版本号为 5，2023 年度会相继发布 0.5, 0.6, 0.7 版本。
 + 修订号：通过修复漏洞或者改进性能来更新程序时，会提升修订号，修订号从 0 开始计数以此加 1。
-+ 发布周期：在未达到 v1.0.0 版本之前，计划每隔 1.5 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
++ 发布周期：在未达到 v1.0.0 版本之前，计划每隔 3 个月发布一个新的次要版本。在此期间，需要持续收集用户反馈，并进行必要的修复和改进。
 + 发布流程：在发布新版本之前，需要进行严格的测试和审核，确保新版本的质量。封板并测试完成后，会在 Github 上发布新版本的源代码，二进制和镜像，并提供详细的文档和使用指南。
 + 版本支持：我们将对最新的版本提供长期支持，包括漏洞修复和安全更新。对于旧版本，我们将提供有限的支持，仅在必要时进行修复。
 
 ## 发布流程与规则
 
 + 特性开发：main 分支主干开发，分支发布，block 用户使用的问题和严重的 bug, 安全隐患，高优先级解决，尽可能保持在一周内收敛，高于一般的功能研发。
-+ 迭代周期：我们的迭代周期通常为 1.5 个月，即每 1.5 个月发布一个新版本。
++ 迭代周期：我们的迭代周期通常为 3 个月，即每 3 个月发布一个新的次要版本。
 + 版本规划：发版前两周产出 alpha 版本，前一周产出 beta 版本，alpha 版本仍可进行特性合并，beta 版本只合并错误修复，最终产出正式版本并打 tag 作为长期保存的 release 分支。
 + 发版计划：在每个发布周期开始时制定详细的发版计划（Github Milestone），包括发布日期、版本号、功能列表和测试计划等。需要尽可能地遵守发版计划，确保按时发布新版本。
 + 发布前测试：在发布新版本之前，需要进行全面的测试，包括单元测试、集成测试，模糊测试，压测，用户验收测试等。只有经过测试并无问题后，我们才会发布新版本。
@@ -32,8 +32,8 @@ KCL 项目版本发布策略如下：
 
 + 设计方案/文档：通过 Issue 回答清楚这个 feature 的动机是什么，它解决什么问题以及目标是什么，用户需求和用户故事是怎样的；这个 feature 做什么，如何做，难度怎样，需要多长时间，依赖项，需要做什么测试等。(Tips: 大的设计尽量拆分成小的设计，通过权衡和广泛的调研找到一个简单且可持续的解决方案，并且具备一定得到可扩展以适应未来的业务或技术变化，通过持续讨论和方案评审确定最终设计)。
 + 编写代码：通过高频小改动进行迭代、持续沟通和协作，提前设计单元测试、集成测试和 benchmark 等测试用例，确保编写代码 100% 测试覆盖，注释完整和逻辑清晰，并通过 Demo 演示持续收集反馈。
-+ 文档撰写：在 kcl-lang.io 中更新用户文档。
-+ 测试和反馈：在发布功能之前，让一些同行/用户通过随循文档来尝试和测试这些新功能。接收反馈并改进。
++ 文档撰写：在 [KCL 网站](https://kcl-lang.io) 中更新用户文档。
++ 测试和反馈：在发布功能之前，让一些同行/用户通过**随循文档**而不是口述来尝试和测试这些新功能。接收反馈并改进。
 + 发布和公告：撰写 Release Note, PR 文章，场景和新特性解读等以及渠道宣发等。
 
 > 注：以上所有信息全是公开的，需要透出给所有社区研发者进行参与、讨论和贡献。