版本发布和维护

本节介绍 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 社区软件包版本	状态	核心版本依赖关系
11.0.0	开发中（未发布）	2.18
10.x 变更日志	当前	2.17
9.x 变更日志	次要/修补程序版本（2024 年 11 月终止支持）	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 版本。

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

`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 支持不与微软提供的 3 年扩展安全更新 (ESU) 支持保持一致，后者是针对已超过微软正常支持结束日期的产品的付费支持选项。

`ansible-core` 支持矩阵 

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

版本	支持	生命周期结束	控制节点 Python	目标 Python / PowerShell
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 日	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 日	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 社区试用新功能，在候选版本上测试现有剧本，并报告他们发现的错误或问题。

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 沟通指南