发行和维护
本节描述了 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 包移植指南,了解有关更新您的剧本以在较新版本的 Ansible 上运行的技巧。对于 Ansible 2.10 和更高版本,您可以使用pip
安装 Ansible 包。有关详细信息,请参阅安装 Ansible。您可以从https://releases.ansible.com/ansible/下载较旧的 Ansible 版本。
Ansible 社区变更日志
此表链接到每个 Ansible 主版本的变更日志。这些变更日志包含每个次要版本中的日期和重大更改。
Ansible 社区包版本 |
状态 |
核心版本依赖项 |
---|---|---|
12.0.0 |
开发中(未发布) |
2.19 |
当前 |
2.18 |
|
10.7 后终止支持 |
2.17 |
|
9.13 后终止支持 |
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 移植指南,了解有关更新您的剧本以在较新版本的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 提供的 3 年扩展安全更新 (ESU
) 支持不一致,后者是 Microsoft 产品超出正常支持结束日期后的付费支持选项。
ansible-core
支持矩阵
此表链接到每个主要ansible-core
版本的变更日志。这些变更日志包含每个次要版本的日期和重大更改。列出的日期表示维护周期的开始日期。
版本 |
支持 |
生命周期结束 |
控制节点 Python |
目标 Python / PowerShell |
---|---|---|---|---|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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沟通指南