发行和维护

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

Ansible 社区软件包	ansible-core
使用新的版本控制（2.10，然后是 3.0.0）	继续使用“经典 Ansible”版本控制（2.11，然后是 2.12）
遵循语义版本控制规则	不使用语义版本控制
一次只维护一个版本	维护最新版本和两个较旧的版本
包括语言、运行时和选定的集合	包括语言、运行时和内置插件
在集合存储库中开发和维护	在 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 停用版本可能在下一个版本的第一个版本发布时或之后不久发布一个最终的维护版本。发生这种情况时，最终维护版本的停用日期为其发布日期。

注意

较旧的、未维护的 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 社区软件包版本	状态	核心版本依赖项
12.0.0	开发中（未发布）	2.19
11.x 变更日志`_	当前	2.18
10.x 变更日志	10.7 后停用	2.17
9.x 变更日志	9.13 后停用	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 的维护持续三个版本。因此，最新版本在其首次发布时会收到安全和常规错误修复，在发布下一个 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 版本开始，每个版本都包含对以下目标节点的支持：

六个最新发布的 Python 版本。
每隔六个 Ansible-core 版本（2.16、2.22 等）的七个最新发布的 Python 版本。

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

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

在 Windows 上运行的 Ansible-core 支持每个 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 支持与 Microsoft 提供的 3 年扩展安全更新 (ESU) 支持不一致，后者是 Microsoft 产品正常支持结束日期后的付费支持选项。

`ansible-core` 支持矩阵 

此表链接到每个主要 Ansible-core 版本的更改日志。这些更改日志包含每个次要版本的发行日期和重大更改。列出的日期表示维护周期的开始日期。

版本	支持	生命周期结束	控制节点 Python	目标 Python/PowerShell
2.17	GA: 2024年5月20日严重: 2024年11月4日安全: 2025年5月19日	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月	2025年5月	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 或 Ansible-core 的新主要版本发布之前，我们至少会创建一个候选版本。候选版本允许 Ansible 社区试用新功能，在候选版本上测试现有 playbook，并报告他们发现的错误或问题。

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

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

如果 RC2 中存在重大问题，则该周期将再次开始，使用另一个候选版本并重复进行，直到维护人员同意所有重大问题都已修复。

开发和维护工作流程 

在版本之间，Ansible 社区开发新功能、维护现有功能以及修复 Ansible-core 和 Ansible 社区包中包含的集合中的错误。

Ansible 社区包工作流程 

Ansible 社区在集合存储库中开发和维护 Ansible 社区包中包含的功能，其工作流程如下所示：

开发人员根据每个集合的贡献规则，将新功能和错误修复添加到各个集合中。

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

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

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

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

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

ansible-core 工作流程 

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

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

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

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

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

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

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

有关在 Ansible-core 中添加功能或修复错误的更多信息，请参阅Ansible 开发周期。

生成更改日志 

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

要将更改日志片段添加到 Ansible 社区包中的集合，我们推荐使用antsibull-changelog 实用程序。

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

贡献者指南: Ansible Core 贡献者和维护者指南
测试策略: 测试策略
Ansible 社区指南: 社区信息和贡献
沟通: 有问题？需要帮助？想分享您的想法？请访问 Ansible 沟通指南