发布与维护

本节介绍两个 Ansible 社区项目的发布周期、规则和维护计划：Ansible 社区软件包和 ansible-core。这两个项目具有不同的版本控制系统、维护结构、内容和工作流。

Ansible 社区软件包	ansible-core
使用新版本控制（2.10，随后 3.0.0）	延续“经典 Ansible”版本控制（2.11，随后 2.12）
遵循语义化版本控制规则	不使用语义化版本控制
每次仅维护一个版本	维护最新版本及两个旧版本
包含语言、运行时和选定的集合（Collections）	包含语言、运行时和内置插件
在集合仓库中开发和维护	在 ansible/ansible 仓库中开发和维护

许多社区用户安装 Ansible 社区软件包。Ansible 社区软件包提供了 Ansible 2.9 中存在的功能，包含超过 85 个集合，内含数千个模块和插件。ansible-core 选项主要针对希望仅安装所需集合的开发者和用户。

发布周期概述 

这两个社区版本是相关的 - 发布周期遵循此模式

发布新的 ansible-core 主版本，例如 ansible-core 2.11
- 发布新的 ansible-core，同时维护之前的两个版本（在本例中为 ansible-base 2.10，Ansible 2.9）
- ansible-core 的新功能开发在 devel 分支中继续
Ansible 社区软件包进行集合冻结（不允许添加新集合或现有集合的新版本）
Ansible 社区软件包候选发布版本，进行测试，根据需要添加额外的候选发布版本
发布基于新 ansible-core 的新 Ansible 社区软件包主版本，例如基于 ansible-core 2.11 的 Ansible 4.0.0
- 最新的 Ansible 社区软件包版本是当前唯一维护的版本
- 新功能开发在集合中继续
- 各个集合可以进行多次次要和主版本发布
每四周发布三个已维护 ansible-core 版本的次要更新（2.11.1）
每四周发布唯一的已维护 Ansible 社区软件包版本的次要更新（4.1.0）
ansible-core 功能冻结
ansible-core 候选发布版本，进行测试，根据需要添加额外的候选发布版本
发布下一个 ansible-core 主版本，周期重新开始

Ansible 社区软件包发布周期 

Ansible 社区团队通常每年发布两个社区软件包主版本，采用灵活的发布周期，滞后于 ansible-core 的发布。此周期可以延长，以便在发布新版本之前对较大的变更进行充分的实施和测试。有关即将发布的版本详情，请参阅 Ansible 路线图。在主版本之间，我们每四周发布一次 Ansible 社区软件包的次要更新。次要更新包括新的向后兼容功能、模块和插件，以及错误修复。

从 2.10 版本开始，Ansible 社区团队保证一次只维护一个主要的社区软件包版本。例如，当发布 Ansible 4.0.0 时，团队将停止制作新的 3.x 版本。如果需要，社区成员可以自行维护旧版本。

注意

每个 Ansible EOL（生命周期结束）版本可能会在下一个版本首次发布时或之后不久发布最后一个维护版本。发生这种情况时，最终的维护版本在发布之日即为 EOL。

注意

较旧的、不再维护的 Ansible 社区软件包版本可能包含未修复的安全漏洞 (CVE)。如果您正在使用不再维护的 Ansible 社区软件包版本，我们强烈建议您尽快升级，以受益于最新的功能和安全修复。

每个 Ansible 社区软件包的主版本都会接受每个包含的集合的最新发布版本以及 ansible-core 的最新发布版本。有关具体的时间表和截止日期，请参阅每个版本的 Ansible 路线图。Ansible 社区软件包的主版本可能包含所包含集合内的模块和其他插件以及核心功能中的重大变更。

Ansible 社区软件包遵循语义化版本控制规则。Ansible 社区软件包的次要更新仅接受所包含集合中的向后兼容更改，即不接受集合的主版本更新。集合也必须使用语义化版本控制，因此集合版本号反映了此规则。例如，如果 Ansible 3.0.0 发布时包含 community.general 2.0.0，则 Ansible 3.x 的所有次要更新（如 Ansible 3.1.0 或 Ansible 3.5.0）必须包含 community.general 的 2.x 版本（如 2.8.0 或 2.9.5），而不是 3.x.x 或更高版本。

集合中的工作在各个集合仓库中进行跟踪。

您可以参考 Ansible 软件包迁移指南获取有关更新 Playbook 以在较新版本 Ansible 上运行的提示。对于 Ansible 2.10 及更高版本，您可以使用 pip 安装 Ansible 软件包。详情请参阅安装 Ansible。您可以从 https://releases.ansible.com/ansible/ 下载较旧的 Ansible 版本。

Ansible 社区变更日志 

此表格提供了每个 Ansible 主版本的变更日志链接。这些变更日志包含每个次要版本中的日期和重大变更。

Ansible 社区软件包版本	状态	Core 版本依赖
14.0.0	开发中（未发布）	2.21
13.x 变更日志	当前 - 最新	2.20
12.x 变更日志	2025 年 12 月 EOL	2.19
11.x 变更日志	2025 年 12 月 EOL	2.18
10.x 变更日志	未维护（已终止支持）	2.17
9.x 变更日志	未维护（已终止支持）	2.16
8.x 变更日志	未维护（已终止支持）	2.15
7.x 变更日志	未维护（已终止支持）	2.14
6.x 变更日志	未维护（已终止支持）	2.13
5.x 变更日志	未维护（已终止支持）	2.12
4.x 变更日志	未维护（已终止支持）	2.11
3.x 变更日志	未维护（已终止支持）	2.10
2.10 变更日志	未维护（已终止支持）	2.10

ansible-core 发布周期 

ansible-core 在灵活的发布周期内进行开发和发布。我们可以延长此周期，以便在发布新版本之前对较大的变更进行充分的实施和测试。有关即将发布的版本详情，请参阅 ansible-core 路线图。

ansible-core 具有分阶段的维护结构，延伸至三个主版本。有关更多信息，请阅读开发与维护工作流，或查看 ansible-core 控制节点 Python 支持中的图表，了解当前版本的维护程度。

注意

较旧的、不再维护的 ansible-core 版本可能包含未修复的安全漏洞 (CVE)。如果您正在使用不再维护的 ansible-core 版本，我们强烈建议您尽快升级，以受益于最新的功能和安全修复。ansible-core 的维护持续 3 个版本。因此，最新版本在首次发布时接收安全和常规错误修复；在下一个 ansible-core 版本发布时，接收安全和关键错误修复；在该版本后续版本发布后，仅接收安全修复。

您可以参考 Ansible Core 迁移指南获取有关更新 Playbook 以在较新版本 ansible-core 上运行的提示。

您可以使用 pip 安装 ansible-core。详情请参阅安装 Ansible。

`ansible-core` 控制节点 Python 支持 

从 ansible-core 2.12 版本开始，每个版本都包括对最近发布的三个 Python 版本的控制节点支持。

`ansible-core` 目标节点 Python 支持 

从 ansible-core 2.16 版本开始，每个版本包括对目标节点的支持：

最近发布的 6 个 Python 版本。
每第 6 个 ansible-core 版本（2.16、2.22 等）支持最近发布的 7 个 Python 版本。

ansible-core 2.16 及更早版本包含对 Python 2.7 的支持。

`ansible-core` 目标节点 PowerShell 和 Windows 支持 

ansible-core 在 Windows 上支持每个 Windows 版本自带的基准 PowerShell 版本。例如，Windows Server 2016 自带 PowerShell 5.1，因此 Ansible 将在 Windows Server 2016 的生命周期内支持 PowerShell 5.1。对每个 Windows 版本的支持由 Windows 生命周期策略决定，并取决于该版本何时达到扩展结束日期。例如，Windows Server 2012 和 2012 R2 的扩展结束日期为 2023 年 10 月 10 日，而 Windows Server 2016 为 2027 年 1 月 12 日。Windows 支持与微软提供的 3 年扩展安全更新 (ESU) 不一致，后者是针对已超出微软正常支持结束日期的产品的付费支持选项。

`ansible-core` 支持矩阵 

此表格提供了每个 ansible-core 主版本的变更日志链接。这些变更日志包含每个次要版本中的日期和重大变更。所列日期指示维护周期的开始日期。

版本	支持情况	生命周期结束	控制节点 Python	目标节点 Python / PowerShell
2.21	GA: 2026 年 5 月关键: 2026 年 11 月安全: 2027 年 5 月	2027 年 11 月	Python 3.12 - 3.14	Python 3.9 - 3.14 PowerShell 5.1 - 7
2.20	GA: 2025 年 11 月 3 日关键: 2026 年 5 月 18 日安全: 2026 年 11 月 2 日	2027 年 5 月	Python 3.12 - 3.14	Python 3.9 - 3.14 PowerShell 5.1
2.19	GA: 2025 年 7 月 21 日关键: 2025 年 11 月 3 日安全: 2026 年 5 月 18 日	2026 年 11 月	Python 3.11 - 3.13	Python 3.8 - 3.13 PowerShell 5.1
2.18	GA: 2024 年 11 月 4 日关键: 2025 年 5 月 19 日安全: 2025 年 11 月 3 日	2026 年 5 月	Python 3.11 - 3.13	Python 3.8 - 3.13 PowerShell 5.1
2.17	GA: 2024 年 5 月 20 日关键: 2024 年 11 月 4 日安全: 2025 年 5 月 19 日	EOL 2025 年 11 月	Python 3.10 - 3.12	Python 3.7 - 3.12 PowerShell 5.1
2.16	GA: 2023 年 11 月 6 日关键: 2024 年 5 月 20 日安全: 2024 年 11 月	EOL 2025 年 7 月	Python 3.10 - 3.12	Python 2.7 Python 3.6 - 3.12 Powershell 5.1
2.15	GA: 2023 年 5 月 22 日关键: 2023 年 11 月 6 日安全: 2024 年 5 月 20 日	EOL 2024 年 11 月	Python 3.9 - 3.11	Python 2.7 Python 3.5 - 3.11 PowerShell 3 - 5.1
2.14	GA: 2022 年 11 月 7 日关键: 2023 年 5 月 22 日安全: 2023 年 11 月 6 日	EOL 2024 年 5 月 20 日	Python 3.9 - 3.11	Python 2.7 Python 3.5 - 3.11 PowerShell 3 - 5.1
2.13	GA: 2022 年 5 月 23 日关键: 2022 年 11 月 7 日安全: 2023 年 5 月 22 日	EOL 2023 年 11 月 6 日	Python 3.8 - 3.10	Python 2.7 Python 3.5 - 3.10 PowerShell 3 - 5.1
2.12	GA: 2021 年 11 月 8 日关键: 2022 年 5 月 23 日安全: 2022 年 11 月 7 日	EOL 2023 年 5 月 22 日	Python 3.8 - 3.10	Python 2.6 - 2.7 Python 3.5 - 3.10 PowerShell 3 - 5.1
2.11	GA: 2021 年 4 月 26 日关键: 2021 年 11 月 8 日安全: 2022 年 5 月 23 日	EOL 2022 年 11 月 7 日	Python 2.7 Python 3.5 - 3.9	Python 2.6 - 2.7 Python 3.5 - 3.9 PowerShell 3 - 5.1
2.10	GA: 2020 年 8 月 13 日关键: 2021 年 4 月 26 日安全: 2021 年 11 月 8 日	EOL 2022 年 5 月 23 日	Python 2.7 Python 3.5 - 3.9	Python 2.6 - 2.7 Python 3.5 - 3.9 PowerShell 3 - 5.1
2.9	GA: 2019 年 10 月 31 日关键: 2020 年 8 月 13 日安全: 2021 年 4 月 26 日	EOL 2022 年 5 月 23 日	Python 2.7 Python 3.5 - 3.8	Python 2.6 - 2.7 Python 3.5 - 3.8 PowerShell 3 - 5.1

`ansible-core` 版本控制 

ansible-core 项目使用历史版本控制方案，与 Python 使用的版本控制方案最相似。

此方案遵循下述详细描述的 X.Y.Z 格式。

X.Y.Z 中的 X 是什么？

X 代表 ansible-core 的内部架构。此处的 X 不暗示任何形式的兼容性，也不代表变更的范围。

v1 可以最好地描述为围绕 ansible.runner.Runner 作为“执行”引擎的内部架构
v2 可以最好地描述为围绕 TaskQueueManager、PlayIterator 以及策略作为“执行”引擎的内部架构

X.Y.Z 中的 Y 是什么？

大约每 6 个月（在 5 月和 11 月），ansible-core 会发布一个主版本。这由 X.Y.Z 版本方案中的 Y 表示。

尽管 Y 表示主版本，但它并不独立引用，而是以 X.Y 的格式指示主版本，例如 2.16。

因此，2.9.0、2.10.0、2.11.0、2.16.0 和 2.19.0 等版本都是主版本发布。X.Y.0 版本并不保证与前一个版本 100% 向后兼容。根据发布的工作范围，有些版本可能影响较大或较小。查看迁移指南以了解可能需要用户干预的变更。

X.Y.Z 中的 Z 是什么？

这是补丁版本。ansible-core 按 4 周的补丁周期运行。主版本的 Z 版本将包含 ansible-core 支持矩阵中概述的错误修复和安全修复。

新版本准备工作 

功能冻结 

在新版本发布的最后准备阶段，核心开发人员和维护者专注于改进候选发布版本，而不是添加或审查新功能。我们可能会实施功能冻结。

功能冻结意味着我们推迟与待发布版本无关的新功能和修复，以便尽快创建新版本。

候选发布版本 

在 Ansible 或 ansible-core 的每个新主版本发布之前，我们都会创建一个或多个候选发布版本。候选发布版本允许 Ansible 社区尝试新功能、在候选版本上测试现有的 Playbook，并报告他们发现的 Bug 或问题。

Ansible 和 ansible-core 会标记第一个候选发布版本 (RC1)，该版本通常持续五个工作日。如果在此期间未发现重大 Bug 或问题，则该候选发布版本将成为最终版本。

如果第一个候选版本存在重大问题，团队和社区会修复它们并标记第二个候选发布版本 (RC2)。此第二个候选版本的持续时间比第一个短。如果 RC2 发布后两个工作日内未报告任何问题，则该候选发布版本将成为最终版本。

如果 RC2 中存在重大问题，周期将从另一个候选发布版本开始，并重复此过程，直到维护者认为所有重大问题都已修复。

开发与维护工作流 

在两次发布之间，Ansible 社区会开发新功能、维护现有功能，并修复 ansible-core 以及 Ansible 社区软件包中包含的集合中的 Bug。

Ansible 社区软件包工作流 

Ansible 社区在集合仓库中开发和维护包含在 Ansible 社区软件包中的功能，工作流如下：

开发人员按照每个集合的贡献规则，向各个集合添加新功能和错误修复。

每个新功能和每个错误修复都包含一个描述该工作的变更日志片段。

发布工程师每四周为当前版本创建一个次要更新，以确保用户能够获得最新的错误修复。

在开发周期结束时，发布工程师会宣布哪些集合以及每个包含集合的哪个主版本将包含在下一个 Ansible 社区软件包版本中。此后不得添加新集合和新主版本，并开始创建新版本的工作。

我们通常不为未维护的 Ansible 社区软件包版本提供修复，但对于关键问题有时会有例外。

有些集合由 Ansible 团队维护，有些由合作伙伴组织维护，有些由社区团队维护。有关添加功能或修复 Ansible 维护的集合中 Bug 的更多信息，请参阅为 Ansible 维护的集合做贡献。

ansible-core 工作流 

Ansible 社区在 GitHub 上开发和维护 ansible-core，工作流如下：

开发人员向 devel 分支添加新功能和错误修复。

每个新功能和每个错误修复都包含一个描述该工作的变更日志片段。

开发团队根据 Bug 的严重程度，将错误修复向后移植到一个、两个或三个稳定分支。他们不会向后移植新功能。

发布工程师每四周为每个已维护版本创建一个次要更新，以确保用户能够获得最新的错误修复。

在开发周期结束时，发布工程师实施功能冻结，并开始创建新版本的工作。

我们通常不为未维护的 ansible-core 版本提供修复，但对于关键问题有时会有例外。

有关在 ansible-core 中添加功能或修复 Bug 的更多信息，请参阅社区指南中的 Ansible 开发周期。

生成变更日志 

我们基于片段生成变更日志。在为现有模块和插件创建新功能或修复 Bug 时，请创建一个描述变更的变更日志片段。新模块或插件不需要变更日志条目。这些项目的详细信息将从模块文档中生成。

要向 Ansible 社区软件包中的集合添加变更日志片段，我们建议使用 antsibull-changelog 工具。

要为 ansible-core 中的新功能和错误修复添加变更日志片段，请参阅社区指南中的变更日志示例和说明。

提交者指南: Ansible Core 贡献者和维护者指南
测试策略: 测试策略
Ansible 社区指南: 社区信息与贡献
交流方式: 有疑问？需要帮助？想分享你的想法？请访问 Ansible 通信指南