发行版和维护

本节描述了 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 的维护持续三个版本。因此，最新版本在首次发布时会收到安全和常规错误修复，在下一个 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 版本。

对 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 日
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 开发周期。

生成变更日志

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

要将变更日志片段添加到 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 沟通指南