OpenHarmony的版本定义和维护

liangkz_梁开祝

发布于 2022-10-2 09:59

浏览

4收藏

OpenHarmony的版本定义和维护

:::

本文来源：
//docs/zh-cn/release-notes/release-definitions/Release-version-definitions.md

9月30日，OpenHarmony在Gitee主页上发布消息：

社区已于09-30发布OpenHarmony-v3.2-Beta3版本, 详情请参考docs仓zh-cn/release-notes/OpenHarmony-v3.2-beta3.md

因此，这次的发布的930版本，并非很多人预期中的大版本（LTS或Release）升级。

对于OpenHarmony代码版本中经常出现的Master、LTS、Release、Beta等关键字，估计会有不少小伙伴感到困惑，这些不同版本之间都有哪些具体的差别？有此疑惑的小伙伴们可以仔细阅读一下Release-version-definitions.md这篇文档：

1. 分支关系

为了保障OpenHarmony社区版本的平滑演进和历史发布版本的持续稳定可靠，OpenHarmony Release sig团队会定期从Master主干分支拉出LTS、Release、Beta等类型的代码分支，并按照OpenHarmony的代码版本生命周期定义对各代码分支进行管理。
OpenHarmony的版本定义和维护-鸿蒙开发者社区

1.1 Master （主干分支）

Master作为OpenHarmony社区持续滚动开发的主干，积极接纳社区每个软件包主干开发分支的代码更新，将其纳入主干实时构建。

1.2 LTS分支（长期支持维护分支）

OpenHarmony社区LTS长期支持维护分支按照每12个月为一个周期在每年的Q3季度从Master主干分支拉出来。该分支在经过集中编译、构建、集成测试并最终通过社区评审发布。

1.3 Release分支（发布分支）

OpenHarmony社区Release分支按照每12个月为一个周期在每年的Q1季度从master主干分支拉出来。该分支在经过集中编译、构建、集成测试并最终通过社区评审发布。Release分支与LTS分支的发布要求一致，但其维护周期短于LTS分支。

1.4 Beta分支（测试分支）

OpenHarmony社区Beta分支是在社区开发和演进过程中不定期从Master主干分支拉出来。该分支仅完成集中编译、构建、基础功能验证，可用于开发调试。

1.5 标签版本

OpenHarmony社区基于LTS分支和Release分支以patch形式合入少量补丁代码，用于解决单点bug、安全漏\洞、以及其他必须的适配修改，经过集成验证之后发布的稳定可靠的标签版本。

2. 维护策略

2.1 生命周期策略

OpenHarmony对已发布的LTS分支和Release分支提供生命周期管理服务，分为两个阶段：

2.1.1 主动维护阶段：发布->停止主动维护

Release sig团队会定期规划维护标签版本计划，用于解决单点bug、安全漏\洞、以及其他必须的修改，以此确保分支持续处于稳定可用状态。

2.2.2 被动维护阶段：停止主动维护->停止维护

Release sig团队不再主动规划和发布标签版本，仅对社区安全漏\洞和严重缺陷在对应分支进行修复。

2.2 LTS/Release分支维护策略

LTS分支：分支发布之日起，提供两年主动维护，并提供1.5年被动维护。

Release分支：分支发布之日起，提供一年主动维护，并提供一年被动维护。

2.3 分支合入管控策略

LTS/Release分支发布后，Release sig团队负责其生命周期管理，在维护周期内，我们只接受安全问题、acts套件问题以及其他重大问题的修复及合入，对应分支的合入会严格管控。目前分支合入管控策略已生效，合入请求需要在committer审查通过后联系对应owner评论approve后合入。