版本：下一个

Releases

发布说明和资源

本节提供了有关发布时间表和发布分支维护的指南。

HAMi 使用语义版本控制模式。HAMi v2.4.0 于 2024 年 9 月发布。该项目遵循给定的版本号 MAJOR.MINOR.PATCH。

主要版本包含大型功能、设计和架构更改，并可能包括不兼容的 API 更改。主要版本发布频率低，并在较长时间内保持稳定。

次要版本包含以向后兼容方式引入的功能、增强和修复。由于 HAMi 是一个快速增长的项目，功能不断快速迭代，每隔几个月发布一个次要版本有助于平衡速度和稳定性。

补丁版本用于向后兼容的错误修复和不影响稳定性或兼容性的非常小的增强。通常只有关键修复会被选入补丁版本。通常在一个次要版本周期中至少会有一个补丁版本。

HAMi 使用 GitHub 标签来管理版本。新版本和候选版本使用通配符标签 v<major>.<minor>.<patch> 发布。

每当 PR 合并到主分支时，CI 将提取最新代码，生成镜像并上传到镜像库。通常可以在线使用最新标签下载 HAMi 组件的最新镜像。每当发布版本时，镜像也会发布，标签与上述发布的标签相同。

非关键问题和功能默认总是添加到下一个次要版本里程碑。

没有解决方法的关键问题会被添加到下一个补丁版本。

发布分支和 PR 的管理如下：

所有更改总是首先提交到 master。
为每个主要或次要版本创建分支。
分支名称将包含版本，例如 release-1.2。
补丁版本从发布分支创建。
对于需要包含在补丁版本中的关键修复，PR 应始终首先合并到 master，然后再挑选到发布分支。PR 需要确保有发布说明撰写，这些描述将在下一个补丁版本中反映。 PR 的挑选过程通过脚本执行。使用方法请参见此处。
对于复杂的更改，特别是关键错误修复，可能需要为 master 和发布分支分别创建 PR。
里程碑标记（例如 v1.4）将添加到 PR 中，这意味着 PR 中的更改是相应版本的内容之一。
在 PR 审查期间，分配选择用于指示审阅者。

次要版本将包含功能、增强和错误修复的混合。

主要功能遵循 HAMi 设计提案流程。您可以参考此处作为提案示例。

在发布开始时，可能会有许多问题分配给发布里程碑。发布的优先级在每两周一次的社区会议中讨论。随着发布的进展，几个问题可能会被移到下一个里程碑。因此，如果一个问题很重要，重要的是在发布周期的早期倡导其优先级。