Ansible 社区包集合要求

概述

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

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

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

反馈和沟通

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

保持知情

要跟踪影响集合的更改

• 加入集合维护者和贡献者论坛组。

• 订阅Ansible 贡献者通讯 The Bullhorn。

沟通和工作组

论坛概述

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

在组织围绕 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)。

  • CoC 必须从README.md 文件链接，或者必须存在于或从集合根目录中的 CODE_OF_CONDUCT.md 文件链接。

  • 建议的方法是链接到 Ansible 的社区行为准则。

  • 如果集合有自己的 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的包参数的最后一个元素来验证此列表。

  plugin_utils：

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

  sub_plugins：

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

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

其他目录

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

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

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

文档要求

集合

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

• 建议在CONTRIBUTING.md或README.md文件中包含贡献者指南。

所有模块和插件

• 必须包含文档块。

• 必须包含示例块（除非与插件类型不相关）。

• 在集合内和集合外引用模块、插件和文档片段时，必须使用全限定类名 (FQCN)，包括ansible-core的ansible.builtin.。

• 对于返回数据的模块和其他插件，必须包含返回值块。

• 向现有集合添加新内容时，必须包含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**上获得您的集合认证，请联系ansiblepartners@redhat.com的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在**两者**上兼容

    • gnu.org许可证列表。

    • Debian自由软件指南。

• 必须使用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 action 工作流文件到您代码库的.github/workflows目录中，以通过 GitHub actions 设置测试。此工作流涵盖了以下所有要求。

及时添加新的ansible-core版本，并考虑停止支持和测试其已终止生命周期 (EOL) 的版本以及您的代码库不支持的版本。

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

为了接收可能影响代码库的重要公告（例如，测试），代码库维护者**应该**

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

• 加入代码库维护者和贡献者论坛小组。

• **必须**从最新的稳定 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文件，为foo.baz指定'>=1.0.0'。

    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主要版本周期中，发布了ansible.netcommon 4.0.0版本。

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

其他要求

• 在内容从其他当前包含的集合（例如community.general或community.network）中移出之后，或者新的集合满足所有要求后，请参阅添加新集合，该内容位于ansible-build-data存储库的README中。

• 指导委员会可以拒绝集合包含请求或将集合从Ansible包中排除，即使该集合满足本文档中列出的要求。有关详细信息，请参阅集合包含请求工作流程。

另见

Ansible集合创建者路径

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