版本发布和维护

本节介绍 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 选项主要针对开发人员和只想安装所需集合的用户。

版本发布周期概述

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

  1. 发布新的 ansible-core 主要版本，例如，ansible-core 2.11

    • 新的 ansible-core 版本发布，现在维护两个之前的版本（在本例中，ansible-base 2.10、Ansible 2.9）

    • ansible-core 的新功能开发工作继续在 devel 分支中进行

  2. Ansible 社区软件包上的集合冻结（没有新的集合或现有集合的新版本）

  3. Ansible 社区软件包的发布候选版本，测试，根据需要提供额外的发布候选版本

  4. 基于新的 ansible-core 发布新的 Ansible 社区软件包主要版本，例如，Ansible 4.0.0 基于 ansible-core 2.11 发布

    • 最新版本的 Ansible 社区软件包是现在唯一维护的版本

    • 新功能的开发工作继续在集合中进行

    • 单个集合可以进行多次次要和主要版本发布

  5. 三个维护的 ansible-core 版本每四周发布一次次要版本（2.11.1）

  6. 单个维护的 Ansible 社区软件包版本每四周发布一次次要版本（4.1.0）

  7. ansible-core 上的功能冻结

  8. ansible-core 的发布候选版本，测试，根据需要提供额外的发布候选版本

  9. 发布下一个 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 软件包移植指南，以获取有关更新剧本以在较新版本的 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 移植指南，以获取有关更新剧本以在较新版本的 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 版本。

对 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 支持不符合 Microsoft 的三年扩展安全更新 (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 日

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 社区包弃用周期

由于 Ansible 是单个集合的软件包，因此弃用周期取决于集合维护人员。我们建议集合维护人员在一个 Ansible 主要版本中弃用一个功能，并且至少在一年的时间内或至少直到下一个 Ansible 主要版本发布之前，不要删除该功能。例如，在 3.1.0 中弃用该功能，并且最早在 5.0.0 或 4.0.0 之前不要删除该功能。集合应该使用语义版本控制，这样在 Ansible 主要版本内不能更改主要集合版本。因此，删除应该在下一个 Ansible 社区包主要版本发布之前进行。这取决于每个集合维护人员，无法保证。

ansible-core 弃用周期

在 ansible-core 中，弃用周期通常跨越 4 个功能版本（2.x，其中 x 表示功能版本）。该功能通常在我们宣布弃用后的第 4 个版本中被移除。例如，在 2.10 中弃用的功能将在 2.13 中移除。跟踪与发布次数相关，与发布编号本身无关。虽然这是标准做法，但有时功能或行为的弃用周期可能基于使用情况或移除的紧迫性而更长或更短。未经意或未记录的功能可能会在没有弃用周期的情况下被移除。在此背景下，未经意功能特指在发布路线图之外出现的紧急功能。

另请参见

贡献者指南

Ansible Core 贡献者和维护者的指南

测试策略

测试策略

Ansible 社区指南

社区信息和贡献

沟通

有问题吗？需要帮助吗？想分享你的想法吗？访问 Ansible 沟通指南