发布与维护
本节描述了 Ansible 两个社区项目的发布周期、规则和维护计划：Ansible 社区包和 ansible-core。这两个项目拥有不同的版本控制系统、维护结构、内容和工作流。
Ansible 社区软件包 |
ansible-core |
|---|---|
使用新版本控制（2.10，然后是 3.0.0） |
延续“经典 Ansible”版本控制（2.11，然后是 2.12） |
遵循语义化版本控制规则 |
不使用语义化版本控制 |
同时仅维护一个版本 |
维护最新版本及之前的两个版本 |
包含语言、运行时和精选集合（Collections） |
包含语言、运行时和内置插件 |
在集合仓库中进行开发和维护 |
在 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）
继续在
devel分支中开发 ansible-core 的新功能
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 生命周期结束（EOL）的版本可能会在下一个版本发布时或发布后不久发出最后一个维护版本。发生这种情况时，最终维护版本在其发布之日即达到生命周期结束。
注意
陈旧、未维护的 Ansible 社区包版本可能包含未修复的安全漏洞（CVE）。如果您正在使用不再维护的 Ansible 社区包版本，我们强烈建议您尽快升级，以享受最新功能和安全修复。
Ansible 社区包的每个主版本都会接受每个已包含集合的最新发布版本以及 ansible-core 的最新发布版本。有关具体的日程安排和截止日期，请参阅每个版本的 Ansible 路线图。Ansible 社区包的主版本可能包含所包含集合的模块和其他插件中的重大变更，以及核心功能中的变更。
Ansible 社区包遵循语义化版本控制规则。Ansible 社区包的次版本仅接受所包含集合中的向后兼容变更，即不允许集合的主版本变更。集合也必须使用语义化版本控制，因此集合版本号会反映此规则。例如，如果 Ansible 3.0.0 发布时包含 community.general 2.0.0，那么 Ansible 3.x 的所有次版本（例如 3.1.0 或 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 社区包发布 |
状态 |
核心版本依赖 |
|---|---|---|
14.0.0 |
开发中（未发布） |
2.21 |
当前版本 - 最新 |
2.20 |
|
2025 年 12 月生命周期结束 |
2.19 |
|
2025 年 12 月生命周期结束 |
2.18 |
|
不再维护（生命周期结束） |
2.17 |
|
不再维护（生命周期结束） |
2.16 |
|
不再维护（生命周期结束） |
2.15 |
|
不再维护（生命周期结束） |
2.14 |
|
不再维护（生命周期结束） |
2.13 |
|
不再维护（生命周期结束） |
2.12 |
|
不再维护（生命周期结束） |
2.11 |
|
不再维护（生命周期结束） |
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 目标节点 Windows 支持
ansible-core 基于 Windows 生命周期策略支持 Windows 目标节点。当目标 Windows 版本达到扩展结束日期时，对该版本的支持即告结束。例如，Windows Server 2012 和 2012 R2 的扩展结束日期为 2023 年 10 月 10 日，而 Windows Server 2016 为 2027 年 1 月 12 日。Windows 支持不与微软提供的 3 年扩展安全更新（ESU）计划挂钩，后者是针对超过正常支持终止日期的产品提供的付费支持选项。
ansible-core 目标节点 PowerShell 支持
Windows 上的 ansible-core 支持 Windows 原生自带的 Windows PowerShell 5.1。从 ansible-core 2.21 版本开始，每个版本还包含对 PowerShell 7.x 最新 LTS 版本的目标节点支持。
PowerShell 7 遵循两年一次的 LTS 发布周期，每个 LTS 版本支持三年。大多数 Ansible 发布版本与单个 PowerShell LTS 版本对齐。然而，每第 5 个 Ansible 发布版本恰逢 PowerShell LTS 过渡期，因此会同时支持即将过期的 LTS 版本和即将进入的 LTS 版本。
即将过期的 LTS 版本在 Ansible 发布的维护窗口期内到达生命周期结束
即将进入的 LTS 版本在 Ansible 发布时处于预览阶段，并在发布前后或几个月内正式发布 (GA)
这种重叠支持使用户能够在旧版本仍获微软支持的同时，规划过渡到新的 PowerShell LTS。
Ansible Core |
PowerShell 版本 |
PowerShell 生命周期 |
注意事项 |
|---|---|---|---|
2.21 |
7.6 LTS |
2026 年 3 月 - 2028 年 11 月 |
标准单 LTS 支持 |
2.22 |
7.6 LTS |
2026 年 3 月 - 2028 年 11 月 |
标准单 LTS 支持 |
2.23 |
7.6 LTS |
2026 年 3 月 - 2028 年 11 月 |
标准单 LTS 支持 |
2.24 |
7.6 LTS, 7.8 LTS |
7.6: 2026 年 3 月 - 2028 年 11 月
7.8: 2027 年 11 月 - 2029 年 11 月
|
重叠 LTS 支持
7.6 在维护窗口期内生命周期结束
7.8 在发布时处于预览状态；约 2028 年 11 月/12 月正式发布
|
2.25 |
7.8 LTS |
2027 年 11 月 - 2029 年 11 月 |
标准单 LTS 支持 |
在此之后的下一个多 LTS 发布版本将是 2.28，届时将支持 PowerShell 7.8 和 7.10。
注意
此处显示的日期基于 Ansible 和 PowerShell 目前的发布时间表，可能会有变动。预计 2027 年 11 月 Ansible 2.24 发布时，PowerShell 7.8 将处于预览阶段，并于同年 11 月至次年 3 月左右正式发布。
ansible-core 支持矩阵
下表提供了每个 ansible-core 主版本更新日志的链接。这些更新日志包含了每个次版本发布的日期和重大变更。列表中的日期表示维护周期开始的日期。
版本 |
支持情况 |
生命周期结束 (EOL) |
控制节点 Python |
目标节点 Python / PowerShell |
|---|---|---|---|---|
2.22 |
GA: 2026 年 11 月
关键: 2027 年 5 月
安全: 2027 年 11 月
|
2028 年 5 月 |
Python 3.13 - 3.15
|
Python 3.9 - 3.15
PowerShell 5.1 - 7
|
GA: 2026 年 5 月
关键: 2026 年 11 月
安全: 2027 年 5 月
|
2027 年 11 月 |
Python 3.12 - 3.14
|
Python 3.9 - 3.14
PowerShell 5.1 - 7
|
|
GA: 2025 年 11 月 03 日
关键: 2026 年 05 月 18 日
安全: 2026 年 11 月 02 日
|
2027 年 5 月 |
Python 3.12 - 3.14
|
Python 3.9 - 3.14
PowerShell 5.1
|
|
GA: 2025 年 07 月 21 日
关键: 2025 年 11 月 03 日
安全: 2026 年 05 月 18 日
|
2026 年 11 月 |
Python 3.11 - 3.13
|
Python 3.8 - 3.13
PowerShell 5.1
|
|
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
|
|
GA: 2024 年 05 月 20 日
关键: 2024 年 11 月 04 日
安全: 2025 年 05 月 19 日
|
EOL
2025 年 11 月
|
Python 3.10 - 3.12
|
Python 3.7 - 3.12
PowerShell 5.1
|
|
GA: 2023 年 11 月 06 日
关键: 2024 年 05 月 20 日
安全: 2024 年 11 月
|
EOL
2025 年 7 月
|
Python 3.10 - 3.12
|
Python 2.7
Python 3.6 - 3.12
Powershell 5.1
|
|
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
|
|
GA: 2022 年 11 月 07 日
关键: 2023 年 05 月 22 日
安全: 2023 年 11 月 06 日
|
EOL
2024 年 5 月 20 日
|
Python 3.9 - 3.11
|
Python 2.7
Python 3.5 - 3.11
PowerShell 3 - 5.1
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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-core 版本控制
ansible-core 项目使用一种历史性的版本控制方案，最类似于 Python 使用的版本控制方案。
该方案遵循 X.Y.Z 的格式，具体说明如下。
X.Y.Z 中的 X 是什么？
X 代表 ansible-core 的内部架构。此处的 X 并不意味着任何形式的兼容性，也不意味着变更范围。
v1可以最好地描述为围绕ansible.runner.Runner作为“执行”引擎的内部架构v2可以最好地描述为围绕TaskQueueManager、PlayIterator和作为“执行”引擎的策略的内部架构
X.Y.Z 中的 Y 是什么？
大约每 6 个月（即 5 月和 11 月），ansible-core 都会发布一个主版本。这由 X.Y.Z 版本方案中的 Y 表示。
尽管 Y 表示主版本，但它不会被单独引用，而是采用 X.Y 的格式来表示主版本，例如 2.16。
因此，诸如 2.9.0、2.10.0、2.11.0、2.16.0 和 2.19.0 等版本均为主版本发布。X.Y.0 发布并不保证与前一个版本百分之百向后兼容。根据版本的工作范围，某些发布的影响可能会更大或更小。请查看移植指南，了解可能需要用户干预的变更。
X.Y.Z 中的 Z 是什么？
这是补丁版本。ansible-core 按 4 周补丁时间表运行。主版本的 Z 发布将包含 ansible-core 支持矩阵 中概述的错误修复和安全修复。
新版本发布准备
功能冻结
在进行新版本发布的最终准备期间，核心开发人员和维护人员专注于改进候选版本，而不是添加或审核新功能。我们可能会实施功能冻结。
功能冻结意味着我们推迟与当前待发布版本无关的新功能和修复，以便我们能尽快创建新版本。
候选发布版本
在每次发布 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 通信指南