Ansible 模块或插件的生命周期

Ansible 主存储库中的模块和插件具有定义的生命周期，从首次引入到最终删除。模块和插件的生命周期与Ansible 发布周期 <release_cycle>相关联。模块或插件可能会经历以下四个阶段

当模块或插件首次被接受到 Ansible 中时，我们认为它处于技术预览阶段，并会在文档中将其标记为这样。
如果模块或插件成熟，则会删除文档中的“预览”标记。这些模块和插件的向后兼容性得到维护，但不保证，这意味着它们的參數应保持稳定的含义。
如果模块或插件的目标 API 发生根本性更改，或者有人创建了其功能的更好实现，我们可能会将其标记为已弃用。已弃用的模块和插件仍然可用，但它们即将达到生命周期结束。我们保留已弃用的模块和插件 4 个发布周期，并提供弃用警告，以帮助用户更新使用它们的 playbook 和角色。
当模块或插件已弃用四个发布周期后，它将被删除，并在路由配置中替换为墓碑条目。已删除的模块和插件不再与 Ansible 一起发布。墓碑条目帮助用户查找替代模块和插件。

对于集合中的模块和插件，生命周期是类似的。自 ansible-base 2.10 起，不再可能将模块标记为“预览”或“稳定”。

弃用 Ansible 主存储库中的模块和插件

要弃用 ansible-core 中的模块，必须：

重命名文件，使其以_开头，例如，将old_cloud.py重命名为_old_cloud.py。这使模块保持可用，并在模块索引页面上将其标记为已弃用。
在相关的更改日志中提及弃用（通过创建一个具有deprecated_features部分的更改日志片段）。
在相关的porting_guide_core_x.y.rst中引用弃用。
在文档中添加deprecated:，并使用以下子值：

removed_in:

一个string，例如"2.10"；Ansible 的版本，其中模块将被仅文档的模块存根替换。通常为当前版本 +4。与 :removed_by_date: 互斥。

remove_by_date:

(在 ansible-base 2.10 中添加)。模块将在新的 Ansible 主要版本中被删除的 ISO 8601 格式的日期。通常为模块弃用日期的 2 年后。与 :removed_in: 互斥。

why:

用于详细说明其被删除原因的可选字符串。

alternatives:

通知用户应该怎么做，例如，Use M(whatmoduletouseinstead) instead.。

有关记录弃用的示例，请参阅此弃用多个模块的 PR。PR 中的一些元素现在可能已过时。

弃用集合中的模块和插件

要弃用集合中的模块，必须：

在meta/runtime.yml中的plugin_routing中添加deprecation条目。例如，要弃用模块old_cloud，请添加：
```
plugin_routing:
    modules:
        old_cloud:
            deprecation:
                removal_version: 2.0.0
                warning_text: Use foo.bar.new_cloud instead.
```
对于其他插件类型，必须将modules:替换为<plugin_type>:，例如查找插件的lookup:。弃用操作插件时，需要添加两个条目：一个用于操作插件，一个用于包含文档的模块文件。

除了removal_version，还可以使用removal_date，并使用 ISO 8601 格式的日期，该日期之后模块将在集合的新主要版本中被删除。
在相关的更改日志中提及弃用。如果集合使用antsibull-changelog，则创建一个具有deprecated_features部分的更改日志片段。
在模块或插件的文档中添加deprecated:，并使用以下子值：

removed_in:

一个string，例如"2.10"；Ansible 的版本，其中模块将被仅文档的模块存根替换。通常为当前版本 +4。与 :removed_by_date: 互斥。

remove_by_date:

(在 ansible-base 2.10 中添加)。模块将在新的 Ansible 主要版本中被删除的 ISO 8601 格式的日期。通常为模块弃用日期的 2 年后。与 :removed_in: 互斥。

why:

用于详细说明其被删除原因的字符串。

alternative:

通知用户应该怎么做，例如，Use M(whatmoduletouseinstead) instead.。有关引用模块以外的实体的方法，请参阅模块文档中的链接。

更改 Ansible 主存储库中模块或插件的名称

还可以重命名模块并保留对旧名称的已弃用别名，方法是使用以 _ 开头的符号链接。此示例允许使用 fileinfo 调用 stat 模块，使以下示例等效：

ln -s stat.py _fileinfo.py
ansible -m stat -a "path=/tmp" localhost
ansible -m fileinfo -a "path=/tmp" localhost

重命名集合中的模块或插件，或将模块或插件重定向到另一个集合

要重命名集合中的模块或插件，或将模块或插件重定向到另一个集合，需要在meta/runtime.yml中的plugin_routing中添加redirect条目。例如，要将模块old_cloud重定向到foo.bar.new_cloud，请添加：

plugin_routing:
    modules:
        old_cloud:
            redirect: foo.bar.new_cloud

如果要弃用旧名称，请添加deprecation:条目（请参见上文）。

plugin_routing:
    modules:
        old_cloud:
            redirect: foo.bar.new_cloud
            deprecation:
                removal_version: 2.0.0
                warning_text: Use foo.bar.new_cloud instead.

即使新模块/插件位于与重定向相同的集合中，也需要使用新模块/插件名称的全限定集合名 (FQCN)。通过使用来自另一个集合的 FQCN，可以将模块/插件重定向到该集合。

如果需要支持 Ansible 2.9，请注意 Ansible 2.9 不知道meta/runtime.yml。使用 Ansible 2.9，仍然可以通过使用符号链接来重命名一个集合内的插件和模块。请注意，ansible-base 2.10、ansible-core 2.11 和更高版本将优先于符号链接使用meta/runtime.yml条目。

在集合中删除模块或插件

要从集合中删除已弃用的模块或插件，需要将其删除：

删除模块或插件文件以及相关的文件，例如测试、文档引用和文档。

在meta/runtime.yml中添加墓碑条目。例如，要删除模块old_cloud，请添加：

plugin_routing:
    modules:
        old_cloud:
            tombstone:
                removal_version: 2.0.0
                warning_text: Use foo.bar.new_cloud instead.

除了removal_version，还可以使用removal_date，并使用 ISO 8601 格式的日期。该日期应为下一个主要版本的日期。