发布和维护

本节介绍 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）

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

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

  3. Ansible 社区包的候选版本、测试、根据需要添加更多候选版本

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

    • 现在仅维护 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 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 社区包版本

状态

核心版本依赖项

12.0.0

正在开发中（未发布）

2.19

11.x 变更日志

当前

2.18

10.x 变更日志

10.7 之后 EOL

2.17

9.x 变更日志

9.13 之后 EOL

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 支持

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 月 04 日
严重：2025 年 05 月 19 日
安全：2025 年 11 月 03 日

2026 年 5 月
Python 3.11 - 3.13
Python 3.8 - 3.13
PowerShell 5.1

2.17
GA：2024 年 05 月 20 日
严重：2024 年 11 月 04 日
安全：2025 年 05 月 19 日

2025 年 11 月
Python 3.10 - 3.12
Python 3.7 - 3.12
PowerShell 5.1

2.16
GA：2023 年 11 月 06 日
严重：2024 年 05 月 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 年 05 月 22 日
严重：2023 年 11 月 06 日
安全：2024 年 05 月 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 月 07 日
严重：2023 年 05 月 22 日
安全：2023 年 11 月 06 日
EOL
2024 年 05 月 20 日
Python 3.9 - 3.11
Python 2.7
Python 3.5 - 3.11
PowerShell 3 - 5.1

2.13
GA：2022 年 05 月 23 日
严重：2022 年 11 月 07 日
安全：2023 年 05 月 22 日
EOL
2023 年 11 月 06 日
Python 3.8 - 3.10
Python 2.7
Python 3.5 - 3.10
PowerShell 3 - 5.1

2.12
GA：2021 年 11 月 08 日
严重：2022 年 05 月 23 日
安全：2022 年 11 月 07 日
EOL
2023 年 05 月 22 日
Python 3.8 - 3.10
Python 2.6 - 2.7
Python 3.5 - 3.10
PowerShell 3 - 5.1

2.11
GA：2021 年 04 月 26 日
严重：2021 年 11 月 08 日
安全：2022 年 05 月 23 日
EOL
2022 年 11 月 07 日
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 年 08 月 13 日
严重：2021 年 04 月 26 日
安全：2021 年 11 月 08 日
EOL
2022 年 05 月 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 年 08 月 13 日
安全：2021 年 04 月 26 日
EOL
2022 年 05 月 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 社区软件包弃用周期

由于 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 通信指南