Ansible 社区包集合要求

概述

本文档描述了包含在 Ansible 社区包中的 Ansible 社区集合维护者的要求。所有包含候选者和已包含的集合必须满足本文档中标有MUST的标准。

您还可以在集合包含标准清单中找到这些要求。

每个被拒绝的候选者都将根据在专用社区主题中做出的决定，从Ansible 社区指导委员会获得反馈。

反馈和沟通

任何反馈和帮助都非常受欢迎。请创建一个社区主题或将您的问题带到社区会议。

保持知情

跟踪影响集合的更改

沟通和工作组

论坛概述

论坛是我们异步的默认通信平台。

在组织围绕 Ansible 集合的沟通方面，您需要了解以下概念

  • 标签：与类别一起，标签是论坛中用于围绕特定主题组织对话的主要功能。大多数 Ansible 项目都有一个或多个关联的标签。对于 Ansible 集合，主要标签名称通常是集合目标的技术：例如，kubernetes.core 的 kubernetes，ansible.windows 的 windows 以及 community.postgresql 的 postgresql。

  • 论坛组：组允许您组织用户、管理权限、拥有提供相关信息的组工作页面、自动订阅成员到标签、提及或消息整个组等等。一个示例集合工作组是PostgreSQL Ansible 集合工作组。

有关更多详细信息，请参阅工作组 - 您可以要求的事情！ 论坛主题。

沟通要求

您的集合

  • 必须在论坛中拥有相应的公共标签，或至少重用一个现有标签。

    • 如果多个集合涵盖类似的主题，则可以共享一个标签；例如，amazon.aws 和 community.aws 都可以使用标签 aws。

    • 此外，集合可以请求论坛组。如果集合请求或已拥有一个组

      • 所有相关标签必须与该组关联。加入该组的每个人都会自动订阅这些标签。

      • 该组必须是公开的，并且任何论坛用户都可以免费加入。

    • 使用请求标签/论坛组主题来请求标签和论坛组。

  • 必须在其 README 中包含一个通信部分，其中包含对论坛的引用，类似于collection_template README.md。

    • 该部分必须至少包含对获取帮助论坛类别的引用，可能包括 URL 中的标签。

    • 该部分必须包含有关参与者应使用哪些标签进行与集合相关的主题的信息。

    • 如果集合具有论坛组，则该部分必须包含对该组的引用。

    • 引用的描述必须欢迎读者加入和参与。

    • 集合的维护者应该订阅所有关联的标签并成为所有关联组的成员。

  • 应该禁用 GitHub 的Discussions 功能，以支持论坛。

    • 除非当前使用 GitHub 讨论，否则必须在存储库上禁用此功能。

集合基础设施

以下指南描述了集合所需的基础设施

  • 必须有一个公开可用的问题跟踪器，该跟踪器不需要付费级别的服务来创建帐户以及创建和查看问题。

  • 必须在其存储库中启用问题功能，并接受任何人的问题报告。

  • 必须拥有与社区行为准则兼容的行为准则 (CoC)。

  • 必须发布到Ansible Galaxy，版本为 1.0.0 或更高版本。

  • 必须仅包含遵循许可规则的对象。

  • 不应包含任何大型对象（二进制文件），与当前 Galaxy tarball 大小限制 20 MB 相比，例如，不要包含用于测试目的的软件包安装程序。

  • 不应包含任何不必要的文件，例如临时文件。

Python 兼容性

除了本节中指定的 Python 要求外，集合还应遵循ansible-and-python-3中的提示。

Python 需求

集合的 Python 需求在 **控制器环境** 和 **其他环境** 之间有所不同。

控制器环境

  • 除非必需库不支持这些 Python 版本，否则集合 **必须** 支持控制器环境中所有符合条件的控制器 Python 版本。 指导委员会 可以根据具体情况授予其他例外。

    • 控制器环境：插件/模块始终在与 ansible-core 本身相同的环境（Python 解释器、venv、主机等）中运行。

    • 符合条件的控制器 Python 版本：控制器端至少一个集合支持的 ansible-core 版本支持的 Python 版本。可以从 ansible-core 支持矩阵 和集合中 meta/runtime.yml 中的 requires_ansible 值确定符合条件的版本。

  • 集合 **必须** 记录控制器环境中 **不支持** 的所有符合条件的控制器 Python 版本。有关详细信息，请参阅 Python 文档要求。

其他环境

  • 除非必需库不支持这些 Python 版本，否则集合 **必须** 支持其他环境中所有符合条件的控制器 Python 版本。 指导委员会 可以根据具体情况授予其他例外。

    • 其他环境：插件/模块不在控制器环境中运行。

    • 符合条件的目标 Python 版本：目标端至少一个集合支持的 ansible-core 版本支持的 Python 版本。可以从 ansible-core 支持矩阵 和集合中 meta/runtime.yml 中的 requires_ansible 值确定符合条件的版本。

  • 集合 **必须** 记录其他环境中不支持的所有符合条件的目标 Python 版本。有关详细信息，请参阅 Python 文档要求。

放弃 Python 版本支持

由于放弃对现有模块/插件的 Python 版本的支持是一种重大更改，因此集合

  • **应该** 在支持被放弃之前，在其先前版本的更改日志中“已弃用功能”部分中宣布。

  • **必须** 发布一个实际放弃支持的主版本。

Python 文档要求

  • 如果您的集合不支持所有符合条件的控制器/目标 Python 版本，则**必须** 在 README 中记录它支持哪些版本。

  • 如果您的集合的大部分都与 ansible-core 支持相同的 Python 版本，但某些模块和插件不支持，则**必须** 在这些模块和插件的文档中包含支持的 Python 版本。

开发模块和插件实用程序的标准

  • module_utils 和 plugin_utils 可以标记为仅供集合内部使用，但**必须** 记录这一点，并且**必须** 对文件名使用前导下划线。

    • 如果您将 module_utils 中的实用程序从公共更改为私有，则您正在进行重大更改。如果您这样做，则必须发布集合的新主版本。

  • 以下是 module_utils 文档的一些建议

    • 无文档字符串：我们为 other-environment 推荐的所有内容都受支持。

    • 文档字符串 'Python versions supported: same as for controller-environment'：我们为 controller-environment 推荐的所有内容都受支持。

    • 带有特定版本的文档字符串：'Python versions supported: '。

存储库结构要求

galaxy.yml

  • **必须** 设置 tags 字段。

  • 集合依赖项**必须** 满足一组规则。有关详细信息，请参阅关于 集合依赖项 的部分。

  • 如果您计划拆分集合，则在较小的集合替换 Ansible 中的较大集合之前，**必须** 批准新的集合。

  • 如果您计划添加其他集合作为依赖项，则**必须** 通过正式的申请流程。

README.md

您的集合存储库**必须** 在集合的根目录中有一个 README.md，请参阅 collection_template/README.md 以获取示例。

meta/runtime.yml

示例：meta/runtime.yml

  • meta/runtime.yml **必须** 使用 requires_ansible 字段定义此集合使用的 ansible-core 的最低版本。例如，如果集合与 ansible-core 2.16 及更高版本一起使用，请在 meta/runtime.yml 文件中设置 requires_ansible: '>=2.16'。

meta/execution-environment.yml

如果集合具有控制器端 Python 包和/或系统包需求，为了方便 执行环境 构建，**应该** 将它们列在 meta 目录下的相应文件中，在 meta/execution-environment.yml 中指定，并 验证。

有关更多信息，请参阅 集合级依赖项指南，并以 collection_template/meta 目录内容为例。

模块和插件

  • 集合**必须** 仅在 plugins/ 目录中使用下面指定的目录，并且仅用于列出的目的

    ansible-core 识别的：

    doc_fragments、modules、module_utils、terminal，以及 使用插件 中列出的那些。可以通过查看 https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/loader.py#L1126 中每个 *_loader 的 package 参数的最后一个元素来验证此列表。

    plugin_utils：

    用于仅在控制器端使用的共享代码，不在模块中。

    sub_plugins：

    对于由集合内部而不是 ansible-core 管理的其他插件。我们使用子文件夹，以便在 ansible-core 添加新的插件类型时不会发生冲突。

    核心团队（维护 ansible-core 的团队）已承诺不将这些目录用于任何与此处指定的用途冲突的用途。

其他目录

  • 集合**必须** 不在任何插件、角色或剧本中使用 meta/、plugins/、roles/ 和 playbooks/ 之外的文件，这些插件、角色或剧本可以通过 FQCN 调用、从其他集合使用或从用户剧本和角色使用。

    • 如果从已安装的集合中删除了除这四个目录及其内容之外的所有文件或目录，则集合**必须** 工作。

    • 内部插件、角色和剧本（仅在测试中使用、仅用于发布集合或仅用于某些其他内部目的且未在外部使用）不受此规则约束，并且可能依赖于其他目录中的文件。

文档要求

集合

  • 必须 使用 链接和格式化宏。

  • 应该 在 CONTRIBUTING.md 或 README.md 文件中提供贡献者指南。

所有模块和插件

  • **必须**包含一个`DOCUMENTATION` 块。

  • **必须**包含一个`EXAMPLES` 块（除非与插件类型无关）。

  • 在集合内部和外部引用模块、插件和文档片段时，**必须**使用 FQCN，包括对 ansible-core 使用`ansible.builtin.`。

  • 对于返回数据的模块和其他插件，**必须**包含一个`RETURN` 块。

  • 向现有集合添加新内容时，**必须**包含`version_added` 字段，例如，对于模块、插件、选项、返回值和属性。

    • 在创建新集合并发布其第一个版本之前，无需添加`version_added`。

    • 集合中对象的`version_added` 字段**必须**引用添加选项的集合版本，**而不是** Ansible 或 ansible-core 的版本。

      • 如果出于某种原因，您需要指定 Ansible 或其他集合的版本号，您**必须**同时提供`version_added_collection: collection_name`。我们强烈建议**不要**这样做。

贡献者工作流程

变更日志

  • 集合**必须**在正确格式中包含变更日志。

    1. 您可以使用antsibull-changelog（文档）生成或检查变更日志，这为包含在`ansible` 包中的集合的变更日志提供了统一性。

版本控制和弃用

  • 集合**必须**遵守语义化版本控制约定

    • **必须**在其集合根目录下的`README.md` 文件中包含此信息。

    • **应该**在其贡献者和维护者文档中包含此信息。

    • **必须**在正确的类别下（`Major changes`、`Minor changes`、`Bugfixes` 等）下包含变更日志条目。

  • 集合**必须**保持向后兼容性。

    • 为了保持对用户的向后兼容性，每个 Ansible 次要版本系列 (x.Y.z) 将使集合的主版本保持不变。

      • 例如，如果 Ansible 3.0.0 包含`community.general` 2.2.0，那么每个 3.Y.z（3.1.z、3.2.z 等）版本都将包含在构建时可用的最新`community.general` 2.y.z 版本。

      • Ansible 3.y.z **永远不会**包含`community.general` 3.y.z 版本，即使它可用。

      • 主要集合版本更改将包含在下一个 Ansible 主要版本（在本例中为 4.0.0）中。

      • 因此，请确保包含在 3.0.0 中的集合的当前主要版本至少接收错误修复，只要生成新的 3.Y.Z 版本。

    • 由于包含了新的次要版本，因此您可以包含新的功能、模块和插件。您**必须**确保您**不会**破坏向后兼容性！这意味着尤其

      • 您可以在`patch releases` 中修复错误，但您**不得**添加新功能或弃用内容。

      • 您可以在`minor releases` 中添加新功能和弃用内容，但您**不得**删除内容或更改现有功能的行为。

      • 您只能在`major releases` 中删除内容或进行重大更改。

      • 有关更多信息，请参阅语义化版本控制。

    • 我们建议您确保如果在包含在 Ansible 3.y.z 中的集合版本中添加了弃用，则删除本身将仅发生在包含在 Ansible 5.0.0 或更高版本中（而不是包含在 Ansible 4.0.0 中）的集合版本中。

  • 集合**应该**以某种方式向贡献者和用户提供其发布和弃用策略，例如，在其 README 或固定问题中。请参阅community.general 中的公告作为示例。

命名

集合命名

在为全新的命名空间选择名称时

  • 请考虑命名空间限制，其中列出了 Galaxy 中命名空间的要求。

  • 如果命名空间尚不存在且未被其他人占用，请提交命名空间请求以创建它。

命名建议

  • 对于`ansible-collections` GitHub 组织下的集合，存储库**应该**命名为`NAMESPACE.COLLECTION`。

  • 对于为处理特定实体而创建的集合，它们应包含实体名称，例如`community.mysql`。

  • 对于公司维护的集合，存储库可以命名为`COMPANY_NAME.PRODUCT_NAME`，例如`ibm.db2`。

  • 避免 FQCN/存储库名称

    • 过长：尝试使其简洁明了。

    • 在`NAMESPACE` 和`COLLECTION` 部分包含相同的单词/词组，例如`my_system.my_system`。

注意

如果您计划在**Red Hat Automation Hub**上获得您的集合认证，请通过`[email protected]` 与 Red Hat 合作伙伴工程部门协商，以确保**Galaxy** 上的社区集合与认证集合之间的集合命名兼容性。

模块命名

  • 仅收集和返回信息的模块**必须**命名为`<something>_info`。

  • 收集和返回`ansible_facts` 的模块**必须**命名为`<something>_facts`，并且**不得**返回除事实之外的任何内容。

有关更多信息，请参阅模块开发指南。

集合许可要求

这些指南是包含在 Ansible 包中的策略，此外还有可能影响您代码的任何许可和法律问题。

注意

以下指南比严格必要的情况更具限制性。一旦我们获得 Red Hat 法律部门的批准，我们将尝试添加更多可接受许可证的列表。

集合中有多种类型的內容，许可必须以不同的方式处理。

  • **必须**使用与GPL-3.0-或更高版本**兼容**的自由软件许可证许可的內容

    • `modules/` 目录內容。

    • `module_utils/` 目录內容：ansible-core 通常使用BSD-2-条款许可证，允许第三方模块在这些第三方模块具有与 GPLv3 不兼容的许可证的情况下使用`module_utils`。在许可您自己的`module_utils` 时，请考虑此用例。

    • `plugins/` 之外的代码：如果它**不**导入`GPL-3.0-or-later` 许可证下的代码，则可以使用另一个与`GPL-3.0-or-later` 兼容的许可证。

    • 非代码內容。

    • 要被允许，许可证**必须**被认为是开源的，并且在**两者**上都与`GPL-3.0-or-later` 兼容

  • **必须**使用GPL-3.0-或更高版本许可的內容

    • `plugins/` 目录中的所有其他代码，除了`modules/` 和`module_utils/` 目录下的代码（见上文）：这些插件在 Ansible 控制器进程内部运行，该进程在`GPL-3.0-or-later` 下获得许可，并且通常必须从控制器导入代码。由于这些原因，**必须**使用`GPL-3.0-or-later`。

    • 位于 plugins/ 目录之外的代码：如果它导入了任何其他受 GPL-3.0-or-later 许可的代码。请注意，这尤其适用于单元测试，这些测试通常会从 ansible-core、plugins/、module_utils/ 或 modules/ 中导入代码，并且此类代码通常受 GPL-3.0-or-later 许可。

贡献者许可协议

集合**不得**要求社区贡献者签署任何类型的贡献者许可协议 (CLA)，除了开发者起源证书 (DCO) 或类似协议，这些协议仅要求确认贡献的来源。此要求旨在维护社区对其贡献的所有权，防止在某个实体拥有整个项目的版权时可能发生的意外许可变更，并降低贡献的门槛。

代码库管理

  • 每个集合**必须**拥有一个公开的 Git 代码库。

  • 集合的发布**必须**在其代码库中进行标记。

    • **必须**使用带有 tag 参数的 git 实用程序来标记发布。

    • 标签名称**必须**与 Galaxy 版本号完全匹配。

    • 标签名称**可以**具有 v 前缀。

    • 标签名称**必须**在每次发布中保持一致的格式。

  • 发布到 Galaxy 的集合工件**必须**从在其 Git 代码库中作为该版本标记的源代码构建。

    • 构建过程中所做的任何更改**必须**明确记录，以便可以重现集合工件。

分支名称和配置

注意

本小节**仅**适用于 ansible-collections 下的代码库！其他集合代码库也可以遵循这些指南，但并非必须。

  • 所有新的代码库**必须**将 main 作为默认分支。

  • 拉取请求设置**必须**不允许 merge commits。

  • 以下分支保护规则**必须**为所有发布分支启用

    • Require linear history

    • Do not allow bypassing the above settings

CI 测试

注意

您可以从 collection_template 代码库的 .github/workflows 目录复制免费使用的 GitHub action 工作流文件，以通过 GitHub actions 设置测试。该工作流涵盖了以下所有要求。

及时添加新的 ansible-core 版本，并考虑停止支持和测试其已结束生命周期的版本以及您的集合不支持的版本。

如果您的集合代码库位于 ansible-collections GitHub 组织下，请记住，测试作业的数量是有限的，并且在组织中的所有集合之间共享。因此，请专注于对您的集合进行良好的测试覆盖，请避免对不必要的实体进行测试，例如您的集合不支持的 ansible-core 已结束生命周期的版本。

为了接收可能影响集合的重要公告（例如，测试），集合维护人员**应该**

  • 订阅 news-for-maintainers 代码库。

  • 加入 Collection Maintainers & Contributors 论坛组。

  • 您**必须**从 最新的稳定 ansible-base/ansible-core 分支 运行 ansible-test sanity 命令。

    • 集合**必须**运行等效于 ansible-test sanity --docker 命令的命令。

      • 如果它们不使用 --docker，则必须确保所有测试都运行，特别是编译和导入测试（这些测试应该针对所有支持的 Python 版本运行）。

      • 集合可以选择跳过它们明确不支持的某些 Python 版本；这需要在 README.md 和每个模块和插件中进行记录（提示：使用文档片段）。但是，我们强烈建议您参考Ansible Python 兼容性部分以获取更多详细信息。

  • 您**应该**另外从 ansible/ansible 的 devel 分支运行 ansible-test sanity，以便您尽早了解新的 lint 要求。

  • 健全性测试**必须**通过。

    • 您**应该**避免向 test/sanity/ignore*.txt 文件中添加条目以使您的测试通过，但允许这样做，除非在下面列出的情况下。

    • 您**不得**忽略以下验证。在批准之前，**必须**修复它们并从文件中删除它们

      • validate-modules:doc-choices-do-not-match-spec

      • validate-modules:doc-default-does-not-match-spec

      • validate-modules:doc-missing-type

      • validate-modules:doc-required-mismatch

      • validate-modules:mutually_exclusive-unknown

      • validate-modules:no-log-needed（在参数规范中使用 no_log=False 来标记误报！）

      • validate-modules:nonexistent-parameter-documented

      • validate-modules:parameter-list-no-elements

      • validate-modules:parameter-type-not-in-doc

    • 以下验证**不得**被忽略，除非在特定情况下

      • validate-modules:undocumented-parameter：这**仅**在以下两种情况之一中被忽略

        1. 一个危险的模块参数已被弃用或删除，并且代码存在于告知用户他们不应该再使用此特定参数或它已故意停止工作。

        2. 模块参数仅用于从伴随的操作插件中传递数据。

    • 所有 ignore-*.txt 文件中的条目**必须**在每个条目的文件中都有一个注释中的理由。例如 plugins/modules/docker_container.py use-argspec-type-path # uses colon-separated paths, can't use type=path。

  • 您**必须**针对集合支持的每个“主要版本”（2.14、2.16、2.17 等）的 ansible-core 运行 CI。（通常是 stable-xxx 分支的 HEAD。）

  • 所有 CI 测试**必须**针对每个拉取请求运行，并且**应该**在合并之前通过。

  • 至少健全性测试**必须**针对发布集合的提交运行；如果它们没有通过，则**不会**发布集合。

    • 如果集合具有集成/单元测试，则它们也**应该**运行；如果它们没有通过，则**应该**分析错误以确定它们是否应该阻止发布。

  • 所有 CI 测试**必须**定期运行（每晚或至少每周一次），以确保没有定期提交的代码库针对从每个测试的 ansible-core 版本测试的 ansible-test 的最新版本进行测试。**必须**定期检查定期 CI 运行的结果。

所有上述内容都可以通过使用 GitHub Action 模板 来实现。

要了解如何向您的集合添加测试，请参阅

在集合之间移动模块时

有关完整详细信息，请参阅 将内容迁移到不同的集合。

通常，我们不反对在集合之间移动内容或将 Ansible 中包含的集合中的内容移动到 Ansible 包之外的集合，只要不违反语义版本控制即可。更准确地说，如果目标集合是原始集合的依赖项，则用重定向替换内容仅是次要更改。（有关向 Ansible 中包含的集合添加新依赖项的更多信息，请参阅 集合依赖项。）

对于社区“通用”集合，我们有一些不同的规则。我们允许在以下条件下将内容从 community.general 和 community.network 移动到 Ansible 之外的其他集合

  1. 新集合具有适当的许可，并遵循 贡献者许可协议 策略。

  2. 在宣布弃用模块的计划后四周内，过去 6 个月内为该内容做出贡献的贡献者均不反对。

  3. 至少有 6 个月的弃用期，在此期间将显示弃用警告。弃用通知必须提到内容已移动到 Ansible 社区包之外的集合，并且用户需要单独安装该集合。

  4. 如果社区成员或贡献者在这 6 个月内提出了取消迁移的充分理由，则指导委员会将在讨论这些理由并进行投票，然后再删除内容。

仅当可以确保完全向后兼容时，才会添加重定向。如果未使用它们，则必须使用墓碑，并且墓碑消息需要明确提及新集合以及新集合中的内容不完全向后兼容。

开发约定

集合中的所有模块

  • **必须**满足 约定、技巧和陷阱 中列出的所有要求。

  • **必须**满足幂等性的概念：如果模块使用相同的输入集重复运行，它不会对系统进行任何更改。

  • **不得**使用特殊 state 选项值（如 get、list、query 或 info）查询信息 - 请改用创建新的 _info 或 _facts 模块（有关更多信息，请参阅模块开发指南）。

  • 所有 *_info 和 *_facts 模块**必须**支持 check_mode（有关更多信息，请参阅开发约定）。

集合依赖关系

符号：如果 foo.bar 依赖于 baz.bam，我们说 baz.bam 是被依赖的集合，而 foo.bar 是依赖集合。

  • 集合**不得**依赖于不包含在 ansible 软件包中的集合。

  • 集合依赖关系**必须**在 Galaxy 上发布。

  • 集合依赖关系**必须**具有版本的下限，且至少为 1.0.0。

    • 这意味着所有集合依赖关系都必须指定版本的下限，并且这些下限应该是稳定的版本，而不是 0.x.y 形式的版本。

    • 在创建集合依赖关系也处于开发阶段的新集合时，您需要注意，因为 Galaxy 会检查所需版本中是否存在依赖关系。

      1. 假设 foo.bar 依赖于 foo.baz。

      2. 首先将 foo.baz 发布为 1.0.0。

      3. 然后修改 foo.bar 的 galaxy.yml 以指定 '>=1.0.0' 用于 foo.baz。

      4. 最后将 foo.bar 发布为 1.0.0。

  • Ansible 中包含的集合之间的依赖关系**必须**有效。如果依赖关系被违反，则相关集合**必须**被固定，以便所有依赖关系再次有效。这意味着保留先前版本的版本号，或者仅部分递增版本号，以便生成的版本集没有无效的依赖关系。

  • 如果某个集合在较长时间内具有过于严格的依赖关系，并迫使另一个被依赖的集合被滞后，则该集合将从下一个主要 Ansible 版本中删除。 “较长时间” 的含义取决于下一个主要 Ansible 版本何时发布。如果某个依赖集合阻止其依赖的集合的新主要版本包含在下一个主要 Ansible 版本中，则该依赖集合将从该主要版本中删除，以避免阻止被依赖的集合。

  • 我们强烈建议集合也针对其依赖关系的 main 分支进行测试，以确保尽早检测到与这些依赖关系的未来版本不兼容的问题，并及时解决这些问题，以避免此类问题。依赖于其他集合的集合必须了解，当它们不确保与最新版本依赖关系兼容时，它们存在被删除的风险。

  • Ansible 中包含的集合**不得**依赖于其他集合，除非它们满足以下情况之一

    1. 它们对 Ansible 中包含的其他集合的一个（或多个）主要版本具有松散的依赖关系。例如，ansible.netcommon: >=1.0.0 或 ansible.netcommon: >=2.0.0, <3.0.0。如果某个集合依赖于此版本范围之外的新主要版本的发行版，而这些发行版将包含在下一个主要 Ansible 版本中，则该依赖集合将从下一个主要 Ansible 版本中删除。此截止日期为功能冻结。

    2. 它们已获得指导委员会的明确许可。

示例

  1. community.foo 1.2.0 依赖于 community.bar >= 1.0.0, < 1.3.0。

    • 现在 community.bar 创建了一个新版本 1.3.0。当 community.foo 未创建具有宽松依赖关系的新版本时，我们必须在下一个 Ansible 版本中包含 community.bar 1.2.x，尽管 1.3.0 可用。

    • 如果 community.foo 在一段时间内未放松其对 community.bar 的依赖关系，则 community.foo 将从下一个主要 Ansible 版本中删除。

    • 不幸的是，community.bar 必须保持在 1.2.x，直到 community.foo 被删除（在下一个主要版本中）或放松其要求，以便可以包含更新的 community.bar 1.3.z 版本。

  2. community.foonetwork 依赖于 ansible.netcommon >= 2.0.0, <3.0.0。

    • ansible.netcommon 4.0.0 在此主要 Ansible 版本周期中发布。

    • community.foonetwork 必须在下一个主要 Ansible 版本的功能冻结之前发布新版本，以允许依赖所有 ansible.netcommon 4.x.y 版本，否则它将从下一个主要 Ansible 版本中删除。

其他要求

另请参阅

Ansible 集合创建者路径

Ansible 集合创建者旅程的一致概述