4 Yocto Project 版本与稳定版本发布流程

Yocto Project 的发布流程具有可预测性，包括主要版本和次要版本（点版本）。 本章简要介绍版本的命名、生命周期和稳定性。

4 主要版本与次要版本的发布节奏

Yocto Project 大约每六个月发布一个主要版本（例如 6.1）， 通常安排在每年四月和十月。以下列出一些主要版本及其代号。 有关主要版本代号的信息，请参阅 “主要版本代号”一节。

  • 4.1 ("Langdale")

  • 4.0 ("Kirkstone")

  • 3.4 ("Honister")

虽然发布节奏无法始终完全一致，但这一时间间隔有利于定期发布， 既能安排充分的质量保证周期，又不会因新版本过多而增加用户负担。 这一节奏可以预测，也避开了不同地区的许多主要节假日。

Yocto Project 不按固定日程发布次要版本（点版本）。 通常，当某个主要版本积累了足够重要的修复或改进时，就会发布点版本。 过去的点版本示例包括：

  • 4.1.3

  • 4.0.8

  • 3.4.4

点版本标记主要版本分支上的一个时间点，该时间点的分支内容经过了 完整的质量保证周期和发布流程验证。

备注

稳定版本分支在补丁就绪后可能随时合入补丁。

4 开发周期

如前面的 主要版本与次要版本的发布节奏 一节所述，每六个月会发布一个新版本。

在这六个月中，Yocto Project 设置了四个“里程碑”版本，代表不同的时间点。 里程碑版本经过 测试与质量保证 流程测试，有助于在正式版本发布之前发现问题。

里程碑版本之间的间隔可能有所不同，但通常会均匀分布在这六个月中。

这些里程碑版本的标签在未来正式版本标签之后加上大写“M”。 例如，在正式的“6.1”版本发布之前， 会发布“6.1M1”、 “6.1M2”和“6.1M3”里程碑标签。

备注

第四个里程碑（M4）不会实际发布并公告，而是代表质量保证团队 开始执行 测试与质量保证 流程的时间点，该流程发生在标记并交付最终版本之前。

第三个里程碑版本（M3）之后，Yocto Project 进入 功能冻结 阶段。 这意味着 OpenEmbedded-Core (OE-Core)、BitBake 及其他核心仓库的维护者停止向“master”分支接受重大变更。 此时可能接受的变更包括核心组件的小幅升级，以及安全修复和缺陷修复。

功能冻结期间，会创建并单独维护一个新分支，用于测试贡献者提交的新功能 和改进；这些变更只有在版本发布后才会进入 master 分支。

4 主要版本代号

每个主要版本都有一个代号，用于在 Yocto Project 源码仓库 中标识该版本。这种做法的理念是：具有相同代号的 Metadata 分支 通常彼此兼容，因此可以一起使用。

备注

主要版本使用代号，是因为 Yocto Project 的版本号（例如 6.1） 可能与某个层或公司的版本方案冲突。代号具有唯一性、有趣且易于识别。

版本也会获得常规版本号，但出于上述原因，仓库中使用代号。 有关 Yocto Project 版本及其代号的信息，见 版本页面。

版本信息 详细介绍如何从一个 Yocto Project 版本迁移到下一个版本。

4 稳定版本流程

版本发布后即进入稳定版本流程，此时会指定一名维护者负责该稳定版本。 维护者通过调查和处理提名补丁及回移工作，跟进该版本的相关活动。 只有首先应用到“master”分支（即当前正在开发的分支）上的修复和改进， 才会被考虑回移到稳定版本。

备注

Yocto Project 当前的回移政策是只考虑缺陷修复和安全修复， 不将新功能回移到稳定版本。这意味着一般的配方版本升级 不太可能获准回移。如果有充分理由，例如升级也是上游首选的修复方式， 则可以例外处理。

4 稳定版本与 LTS 的补丁接收政策

所有变更必须已被当前 master 版本以及其他仍处于稳定支持期内的版本接受。

可以接受：

  • 安全与 CVE 修复

  • 缺陷修复

  • 跟随上游稳定系列或 LTS 的版本更新，前提是其与原始版本在兼容性上保持一致。 详情见 稳定点版本升级。

备注

一旦配方的 UPSTREAM_STABLE_RELEASE_REGEX 获得接受， 符合该模式的版本升级默认视为可以接受。 如果上游未遵守自己的稳定版本准则，仍可按通常方式拒绝升级。

可能接受：

  • 使代码能够在新发布的发行版上工作的修复，例如更新 uninative 压缩包，或修复 Build Host 上新版 GCC 导致的构建问题。

不可接受：

  • 一般版本升级

  • 新功能

  • 破坏 ABI/API 兼容性的变更

  • 元数据改进和重构，除非它们是某项必要修复的依赖

备注

对这些规则的例外必须获得 TSC 批准。

4 稳定点版本升级

某些上游项目维护的稳定分支仅收集缺陷修复和安全补丁， 这与 Yocto Project 自身的稳定版本政策类似。 对于跟踪此类上游项目的配方，可以进行 稳定点版本升级 （例如从 1.0.2 升级到 1.0.3），而不局限于接受回移补丁。 这就是上述“可以接受跟随上游稳定系列的版本更新”政策背后的机制。

4 符合条件的上游项目标准

为配方设置 UPSTREAM_STABLE_RELEASE_REGEX， 意味着按照 OpenEmbedded 的标准，可以有把握地将某些版本升级 视为稳定点版本升级。随后， 自动升级助手（AUH） 会在稳定版本期间自动发送升级这些配方的补丁。

备注

未设置该变量的配方仍可向稳定分支提交升级补丁，但接受门槛较高。 提交说明需要解释该版本升级为何符合稳定分支政策， 或者说明接受此次升级的特殊理由。

满足以下标准时，可以为配方设置 UPSTREAM_STABLE_RELEASE_REGEX：

  1. 存在上游稳定分支 --- 上游项目维护以稳定版本部分命名的分支， 且有证据表明这些分支只包含缺陷修复和安全修复， 不增加新功能，也不破坏 ABI/API 兼容性。例如，util-linux 的 2.41.3 版本号有三个部分，而上游的 stable/v2.41 等分支 使用两个部分。这表明第三部分的递增（例如从 2.41.3 到 2.41.4） 属于稳定点版本。类似地，systemd 维护 stable/v259-stable 分支。

此外，至少满足以下条件之一：

  1. 上游维护者确认 --- 上游项目维护者明确确认， 版本号某个部分的递增只包含缺陷修复。

  2. 有明确的历史证据或公认惯例 --- 项目的变更历史清楚表明， 某类版本号递增只包含缺陷修复，或者这一点是公认的约定。 例如，openssh 的 p 后缀递增（从 10.2p1 到 10.2p2）， 以及 kmod 的补丁级版本递增，历来都只包含缺陷修复。

备注

设置 UPSTREAM_STABLE_RELEASE_REGEX 的补丁应首先提交到 master 分支，遵循正常审查流程。在 master 接受之后， 可以回移到稳定版本分支。必要时可以例外处理， 例如某配方已从 master 删除，但需要在稳定分支上为其设置 UPSTREAM_STABLE_RELEASE_REGEX。

4 稳定版本正则表达式的工作方式

稳定点版本升级机制使用 过滤正则表达式 限制上游版本检查， 使其只考虑同一稳定系列中的版本。配方设置 UPSTREAM_STABLE_RELEASE_REGEX 后，BitBake 获取器 （git、wget、crate）中的版本检查基础设施会应用该正则表达式， 过滤发现的上游版本。只有匹配该表达式的版本才被视为升级候选。

例如，配方当前版本为 1.4.2，正则表达式为 ^1\.4(\.\d+)*$， 则 1.4.7 是有效的升级候选，而 1.5.0 不是。

对于版本号以点分隔的配方，upstream-stable-release-point 类可以自动生成此正则表达式。对于其他版本方案， 请在配方中直接设置 UPSTREAM_STABLE_RELEASE_REGEX。

4 长期支持版本

稳定版本的支持期为七个月，而 Yocto Project 现在为某些特定版本提供 更长时间的支持，这些版本称为长期支持（LTS）版本。

发现重大问题时，除当前稳定版本外，仍在支持期内的 LTS 版本 也可以获得修复。已经结束生命周期（EOL）的旧稳定版本则不会收到这些更新。

这一机制始于 2020 年 4 月发布的 3.1（“Dunfell”）版本。 项目最初承诺支持两年，后来延长为四年。

每两年发布一个新的 LTS 版本，支持期为四年。 这为项目用户提供了更高的稳定性，也留出了更多时间升级到下一个 LTS 版本。

当前受支持的 LTS 版本为：

  • 6.0（“Wrynose”），2026 年 5 月发布，支持到 2030 年 4 月。

  • 5.0（“Scarthgap”），2024 年 4 月发布，支持到 2028 年 4 月。

有关稳定版本和 LTS 版本管理的详情， 请参阅 https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS。

本文档针对 Blacksail 版本构建。

../_images/releases.svg

备注

在某些情况下，社区可以创建一个层，为 LTS 版本增加特定功能 或支持某个软件包的新版本。这称为 Mixin 层。 这些层规模小、用途明确，可以叠加到 LTS 版本上， 将特定功能“混入”构建。它们按需创建，由需要这些功能的人负责维护。

这些层的测试政策取决于使用范围，按具体情况决定。 meta-lts-mixins 仓库中提供了一些 Mixin 层。Yocto Project 为这些仓库提供托管，但不提供测试。 更广泛的社区也可能在其他地方发布 Mixin 层。

4 测试与质量保证

通过执行测试策略进行质量保证，是 Yocto Project 开发和发布流程的一部分。 测试策略让 Yocto Project 团队能够确保版本经过验证。 此外，开发者可以查看这些策略，并据此验证自己的项目。 本节概述 Yocto Project 使用的测试基础设施。 有关如何在自己的项目上运行可用测试的信息，请参阅《Yocto Project 测试环境手册》的 “执行自动化运行时测试”一节。

质量保证与测试基础设施已深入集成到项目中，核心开发者对其中一部分 已习以为常。这些基础设施包含以下组成部分：

  • bitbake-selftest：独立命令，对 BitBake 及其获取器的关键部分 运行单元测试。

  • sanity：自动包含的类，检查构建环境是否缺少工具 （例如 gcc），或存在常见配置错误，例如 MACHINE 设置不正确。

  • insane：检查构建产物是否合理。 例如，为 ARM 目标构建时，应生成 ARM 二进制文件； 如果生成的是 PPC 二进制文件，就说明存在问题。

  • testimage：在镜像构建完成后执行运行时测试。 测试通常通过 QEMU 启动镜像， 检查集成后的运行时启动行为和功能。 也可以通过机器的 IP 地址对其进行测试。

  • ptest： 对特定软件在构建期间生成的软件包运行测试， 允许在目标镜像中运行这些软件包的测试。

  • oe-selftest：测试各种 BitBake 调用组合。 这些测试在 OpenEmbedded 构建系统自身之外运行。 oe-selftest 默认可以运行全部测试，也可以运行指定测试或测试套件。

最初，这些测试中的很多都依赖手动执行。后来，项目投入大量工作实现测试 自动化，以便更多人使用，并让 Yocto Project 开发团队更快、更高效地运行测试。

Yocto Project 的主要 Autobuilder 公开测试各个版本在 openembedded-core、 meta-yocto 和 bitbake 仓库中的代码。测试既覆盖“master”分支的当前状态，也覆盖新提交的补丁。 对提交补丁的测试通常在 openembedded-core、 meta-yocto 和 bitbake 仓库的“master-next”分支中进行。

备注

可以在 Yocto Project 源码仓库 中找到所有这些分支。

在这些公开分支中运行测试，以公开可见的方式确保 OE-Core 中主要支持的 架构和配方都能成功构建并正确运行。

版本的质量保证流程会测试 multilib、子架构和配置 （例如 x32、poky-tiny、musl、no-x11 等）等各类功能， 并运行 bitbake-selftest 和 oe-selftest。 Autobuilder 工作节点完成一个版本的完整测试和验证需要数小时。

备注

Autobuilder 工作节点并不完全相同，因此会定期在多种 Linux 发行版上测试。 Autobuilder 仅测试基于 QEMU 的环境，不测试真实硬件。

最后，除了 Autobuilder 测试，Yocto Project 质量保证团队还会在包括 真实硬件在内的多种平台上执行测试，确保获得预期结果。