replace porting guides with stub pages - issue 71687 (#71988) (#72599)

(cherry picked from commit 5a3a2d1a39a610a820ec0142b93b0200222c05f3)

9 files changed, 38 insertions, 2915 deletions

diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.0.rst b/docs/docsite/rst/porting_guides/porting_guide_2.0.rst
index 022499be2b..00879a6bb0 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_2.0.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_2.0.rst
@@ -1,396 +1,13 @@
+:orphan:
+
 .. _porting_2.0_guide:
 
 *************************
 Ansible 2.0 Porting Guide
 *************************
 
-This section discusses the behavioral changes between Ansible 1.x and Ansible 2.0.
-
-It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
-
-
-We suggest you read this page along with `Ansible Changelog for 2.0 <https://github.com/ansible/ansible/blob/stable-2.0/CHANGELOG.md>`_ to understand what updates you may need to make.
-
-This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
-
-.. contents:: Topics
-
-Playbook
-========
-
-This section discusses any changes you may need to make to your playbooks.
-
-.. code-block:: yaml
-
-    # Syntax in 1.9.x
-    - debug:
-        msg: "{{ 'test1_junk 1\\\\3' | regex_replace('(.*)_junk (.*)', '\\\\1 \\\\2') }}"
-    # Syntax in 2.0.x
-    - debug:
-        msg: "{{ 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') }}"
-
-    # Output:
-    "msg": "test1 1\\3"
-
-To make an escaped string that will work on all versions you have two options::
-
-- debug: msg="{{ 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') }}"
-
-uses key=value escaping which has not changed.  The other option is to check for the ansible version::
-
-"{{ (ansible_version|version_compare('2.0', 'ge'))|ternary( 'test1_junk 1\\3' | regex_replace('(.*)_junk (.*)', '\\1 \\2') , 'test1_junk 1\\\\3' | regex_replace('(.*)_junk (.*)', '\\\\1 \\\\2') ) }}"
-
-* trailing newline When a string with a trailing newline was specified in the
-  playbook via yaml dict format, the trailing newline was stripped. When
-  specified in key=value format, the trailing newlines were kept. In v2, both
-  methods of specifying the string will keep the trailing newlines. If you
-  relied on the trailing newline being stripped, you can change your playbook
-  using the following as an example::
-
-    # Syntax in 1.9.x
-    vars:
-      message: >
-        Testing
-        some things
-    tasks:
-    - debug:
-        msg: "{{ message }}"
-
-    # Syntax in 2.0.x
-    vars:
-      old_message: >
-        Testing
-        some things
-      message: "{{ old_messsage[:-1] }}"
-    - debug:
-        msg: "{{ message }}"
-    # Output
-    "msg": "Testing some things"
-
-* Behavior of templating DOS-type text files changes with Ansible v2.
-
-  A bug in Ansible v1 causes DOS-type text files (using a carriage return and newline) to be templated to Unix-type text files (using only a newline). In Ansible v2 this long-standing bug was finally fixed and DOS-type text files are preserved correctly. This may be confusing when you expect your playbook to not show any differences when migrating to Ansible v2, while in fact you will see every DOS-type file being completely replaced (with what appears to be the exact same content).
-
-* When specifying complex args as a variable, the variable must use the full jinja2
-  variable syntax (```{{var_name}}```) - bare variable names there are no longer accepted.
-  In fact, even specifying args with variables has been deprecated, and will not be
-  allowed in future versions::
-
-    ---
-    - hosts: localhost
-      connection: local
-      gather_facts: false
-      vars:
-        my_dirs:
-          - { path: /tmp/3a, state: directory, mode: 0755 }
-          - { path: /tmp/3b, state: directory, mode: 0700 }
-      tasks:
-        - file:
-          args: "{{item}}" # <- args here uses the full variable syntax
-          with_items: "{{my_dirs}}"
-
-* porting task includes
-* More dynamic. Corner-case formats that were not supposed to work now do not, as expected.
-* variables defined in the yaml dict format https://github.com/ansible/ansible/issues/13324
-* templating (variables in playbooks and template lookups) has improved with regard to keeping the original instead of turning everything into a string.
-  If you need the old behavior, quote the value to pass it around as a string.
-* Empty variables and variables set to null in yaml are no longer converted to empty strings. They will retain the value of `None`.
-  You can override the `null_representation` setting to an empty string in your config file by setting the :envvar:`ANSIBLE_NULL_REPRESENTATION` environment variable.
-* Extras callbacks must be whitelisted in ansible.cfg. Copying is no longer necessary but whitelisting in ansible.cfg must be completed.
-* dnf module has been rewritten. Some minor changes in behavior may be observed.
-* win_updates has been rewritten and works as expected now.
-* from 2.0.1 onwards, the implicit setup task from gather_facts now correctly inherits everything from play, but this might cause issues for those setting
-  `environment` at the play level and depending on `ansible_env` existing. Previously this was ignored but now might issue an 'Undefined' error.
-
-Deprecated
-----------
-
-While all items listed here will show a deprecation warning message, they still work as they did in 1.9.x. Please note that they will be removed in 2.2 (Ansible always waits two major releases to remove a deprecated feature).
-
-* Bare variables in ``with_`` loops should instead use the ``"{{ var }}"`` syntax, which helps eliminate ambiguity.
-* The ansible-galaxy text format requirements file. Users should use the YAML format for requirements instead.
-* Undefined variables within a ``with_`` loop's list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error.
-* Using dictionary variables to set all task parameters is unsafe and will be removed in a future version. For example::
-
-    - hosts: localhost
-      gather_facts: no
-      vars:
-        debug_params:
-          msg: "hello there"
-      tasks:
-        # These are both deprecated:
-        - debug: "{{debug_params}}"
-        - debug:
-          args: "{{debug_params}}"
-
-        # Use this instead:
-        - debug:
-            msg: "{{debug_params['msg']}}"
-
-* Host patterns should use a comma (,) or colon (:) instead of a semicolon (;) to separate hosts/groups in the pattern.
-* Ranges specified in host patterns should use the [x:y] syntax, instead of [x-y].
-* Playbooks using privilege escalation should always use "become*" options rather than the old su*/sudo* options.
-* The "short form" for vars_prompt is no longer supported.
-  For example::
-
-    vars_prompt:
-        variable_name: "Prompt string"
-
-* Specifying variables at the top level of a task include statement is no longer supported. For example::
-
-    - include_tasks: foo.yml
-        a: 1
-
-Should now be::
-
-    - include_tasks: foo.yml
-      vars:
-        a: 1
-
-* Setting any_errors_fatal on a task is no longer supported. This should be set at the play level only.
-* Bare variables in the `environment` dictionary (for plays/tasks/etc.) are no longer supported. Variables specified there should use the full variable syntax: '{{foo}}'.
-* Tags (or any directive) should no longer be specified with other parameters in a task include. Instead, they should be specified as an option on the task.
-  For example::
-
-    - include_tasks: foo.yml tags=a,b,c
-
-  Should be::
-
-    - include_tasks: foo.yml
-      tags: [a, b, c]
-
-* The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup ('first_found', …) plugin.
-
-
-Other caveats
--------------
-
-Here are some corner cases encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored.
-
-* Bad variable composition::
-
-    with_items: myvar_{{rest_of_name}}
-
-  This worked 'by accident' as the errors were retemplated and ended up resolving the variable, it was never intended as valid syntax and now properly returns an error, use the following instead.::
-
-    hostvars[inventory_hostname]['myvar_' + rest_of_name]
-
-* Misspelled directives::
-
-    - task: dostuf
-      becom: yes
-
-  The task always ran without using privilege escalation (for that you need `become`) but was also silently ignored so the play 'ran' even though it should not, now this is a parsing error.
-
-
-* Duplicate directives::
-
-    - task: dostuf
-      when: True
-      when: False
-
-  The first `when` was ignored and only the 2nd one was used as the play ran w/o warning it was ignoring one of the directives, now this produces a parsing error.
-
-* Conflating variables and directives::
-
-    - role: {name=rosy, port=435 }
-
-    # in tasks/main.yml
-    - wait_for: port={{port}}
-
-  The `port` variable is reserved as a play/task directive for overriding the connection port, in previous versions this got conflated with a variable named `port` and was usable
-  later in the play, this created issues if a host tried to reconnect or was using a non caching connection. Now it will be correctly identified as a directive and the `port` variable
-  will appear as undefined, this now forces the use of non conflicting names and removes ambiguity when adding settings and variables to a role invocation.
-
-* Bare operations on `with_`::
-
-    with_items: var1 + var2
-
-  An issue with the 'bare variable' features, which was supposed only template a single variable without the need of braces ({{ )}}, would in some versions of Ansible template full expressions.
-  Now you need to use proper templating and braces for all expressions everywhere except conditionals (`when`)::
-
-    with_items: "{{var1 + var2}}"
-
-  The bare feature itself is deprecated as an undefined variable is indistinguishable from a string which makes it difficult to display a proper error.
-
-Porting plugins
-===============
-
-In ansible-1.9.x, you would generally copy an existing plugin to create a new one. Simply implementing the methods and attributes that the caller of the plugin expected made it a plugin of that type. In ansible-2.0, most plugins are implemented by subclassing a base class for each plugin type. This way the custom plugin does not need to contain methods which are not customized.
-
-
-Lookup plugins
---------------
-
-* lookup plugins ; import version
-
-
-Connection plugins
-------------------
-
-* connection plugins
-
-Action plugins
---------------
-
-
-* action plugins
-
-Callback plugins
-----------------
-
-Although Ansible 2.0 provides a new callback API the old one continues to work
-for most callback plugins.  However, if your callback plugin makes use of
-:attr:`self.playbook`, :attr:`self.play`, or :attr:`self.task` then you will
-have to store the values for these yourself as ansible no longer automatically
-populates the callback with them.  Here's a short snippet that shows you how:
-
-.. code-block:: python
-
-    import os
-    from ansible.plugins.callback import CallbackBase
-
-    class CallbackModule(CallbackBase):
-        def __init__(self):
-            self.playbook = None
-            self.playbook_name = None
-            self.play = None
-            self.task = None
-
-        def v2_playbook_on_start(self, playbook):
-            self.playbook = playbook
-            self.playbook_name = os.path.basename(self.playbook._file_name)
-
-        def v2_playbook_on_play_start(self, play):
-            self.play = play
-
-        def v2_playbook_on_task_start(self, task, is_conditional):
-            self.task = task
-
-        def v2_on_any(self, *args, **kwargs):
-            self._display.display('%s: %s: %s' % (self.playbook_name,
-            self.play.name, self.task))
-
-
-Connection plugins
-------------------
-
-* connection plugins
-
-
-Hybrid plugins
-==============
-
-In specific cases you may want a plugin that supports both ansible-1.9.x *and* ansible-2.0. Much like porting plugins from v1 to v2, you need to understand how plugins work in each version and support both requirements.
-
-Since the ansible-2.0 plugin system is more advanced, it is easier to adapt your plugin to provide similar pieces (subclasses, methods) for ansible-1.9.x as ansible-2.0 expects. This way your code will look a lot cleaner.
-
-You may find the following tips useful:
-
-* Check whether the ansible-2.0 class(es) are available and if they are missing (ansible-1.9.x) mimic them with the needed methods (e.g. ``__init__``)
-
-* When ansible-2.0 python modules are imported, and they fail (ansible-1.9.x), catch the ``ImportError`` exception and perform the equivalent imports for ansible-1.9.x. With possible translations (e.g. importing specific methods).
-
-* Use the existence of these methods as a qualifier to what version of Ansible you are running. So rather than using version checks, you can do capability checks instead. (See examples below)
-
-* Document for each if-then-else case for which specific version each block is needed. This will help others to understand how they have to adapt their plugins, but it will also help you to remove the older ansible-1.9.x support when it is deprecated.
-
-* When doing plugin development, it is very useful to have the ``warning()`` method during development, but it is also important to emit warnings for deadends (cases that you expect should never be triggered) or corner cases (e.g. cases where you expect misconfigurations).
-
-* It helps to look at other plugins in ansible-1.9.x and ansible-2.0 to understand how the API works and what modules, classes and methods are available.
-
-
-Lookup plugins
---------------
-
-As a simple example we are going to make a hybrid ``fileglob`` lookup plugin.
-
-.. code-block:: python
-
-    from __future__ import (absolute_import, division, print_function)
-    __metaclass__ = type
-
-    import os
-    import glob
-
-    try:
-        # ansible-2.0
-        from ansible.plugins.lookup import LookupBase
-    except ImportError:
-        # ansible-1.9.x
-
-        class LookupBase(object):
-            def __init__(self, basedir=None, runner=None, **kwargs):
-                self.runner = runner
-                self.basedir = self.runner.basedir
-
-            def get_basedir(self, variables):
-                return self.basedir
-
-    try:
-        # ansible-1.9.x
-        from ansible.utils import (listify_lookup_plugin_terms, path_dwim, warning)
-    except ImportError:
-        # ansible-2.0
-        from ansible.utils.display import Display
-        warning = Display().warning
-
-    class LookupModule(LookupBase):
-
-        # For ansible-1.9.x, we added inject=None as valid argument
-        def run(self, terms, inject=None, variables=None, **kwargs):
-
-            # ansible-2.0, but we made this work for ansible-1.9.x too !
-            basedir = self.get_basedir(variables)
-
-            # ansible-1.9.x
-            if 'listify_lookup_plugin_terms' in globals():
-                terms = listify_lookup_plugin_terms(terms, basedir, inject)
-
-            ret = []
-            for term in terms:
-                term_file = os.path.basename(term)
-
-                # For ansible-1.9.x, we imported path_dwim() from ansible.utils
-                if 'path_dwim' in globals():
-                    # ansible-1.9.x
-                    dwimmed_path = path_dwim(basedir, os.path.dirname(term))
-                else:
-                    # ansible-2.0
-                    dwimmed_path = self._loader.path_dwim_relative(basedir, 'files', os.path.dirname(term))
-
-                globbed = glob.glob(os.path.join(dwimmed_path, term_file))
-                ret.extend(g for g in globbed if os.path.isfile(g))
-
-            return ret
-
-.. Note:: In the above example we did not use the ``warning()`` method as we had no direct use for it in the final version. However we left this code in so people can use this part during development/porting/use.
-
-
-
-Connection plugins
-------------------
-
-* connection plugins
-
-Action plugins
---------------
-
-* action plugins
-
-Callback plugins
-----------------
-
-* callback plugins
-
-Connection plugins
-------------------
-
-* connection plugins
-
-
-Porting custom scripts
-======================
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel Ansible 2.0 Porting guide <https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.0.html>`_ for up to date information.
 
-Custom scripts that used the ``ansible.runner.Runner`` API in 1.x have to be ported in 2.x.  Please refer to: :ref:`developing_api`
+.. note::
 
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.3.rst b/docs/docsite/rst/porting_guides/porting_guide_2.3.rst
index 424625746d..a003ba3f69 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_2.3.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_2.3.rst
@@ -1,232 +1,13 @@
+:orphan:
+
 .. _porting_2.3_guide:
 
 *************************
 Ansible 2.3 Porting Guide
 *************************
 
-This section discusses the behavioral changes between Ansible 2.2 and Ansible 2.3.
-
-It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
-
-
-We suggest you read this page along with `Ansible Changelog for 2.3 <https://github.com/ansible/ansible/blob/stable-2.3/CHANGELOG.md>`_ to understand what updates you may need to make.
-
-This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
-
-.. contents:: Topics
-
-Playbook
-========
-
-Restructued async to work with action plugins
----------------------------------------------
-
-In Ansible 2.2 (and possibly earlier) the `async:` keyword could not be used in conjunction with the action plugins such as `service`. This limitation has been removed in Ansible 2.3
-
-**NEW** In Ansible 2.3:
-
-
-.. code-block:: guess
-
-    - name: Install nginx asynchronously
-      service:
-        name: nginx
-        state: restarted
-      async: 45
-
-
-OpenBSD version facts
----------------------
-
-The `ansible_distribution_release` and `ansible_distribution_version` facts on OpenBSD hosts were reversed in Ansible 2.2 and earlier. This has been changed so that version has the numeric portion and release has the name of the release.
-
-**OLD** In Ansible 2.2 (and earlier)
-
-
-.. code-block:: guess
-
-    "ansible_distribution": "OpenBSD"
-    "ansible_distribution_release": "6.0",
-    "ansible_distribution_version": "release",
-
-**NEW** In Ansible 2.3:
-
-
-.. code-block:: guess
-
-    "ansible_distribution": "OpenBSD",
-    "ansible_distribution_release": "release",
-    "ansible_distribution_version": "6.0",
-
-
-Names Blocks
-------------
-
-Blocks can now have names, this allows you to avoid the ugly `# this block is for...` comments.
-
-
-**NEW** In Ansible 2.3:
-
-
-.. code-block:: guess
-
-    - name: Block test case
-      hosts: localhost
-      tasks:
-       - name: Attempt to setup foo
-         block:
-           - debug: msg='I execute normally'
-           - command: /bin/false
-           - debug: msg='I never execute, cause ERROR!'
-         rescue:
-           - debug: msg='I caught an error'
-           - command: /bin/false
-           - debug: msg='I also never execute :-('
-         always:
-           - debug: msg="this always executes"
-
-
-Use of multiple tags
---------------------
-
-Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last specified tag overriding all the other specified tags. This behaviour is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behaviour.
-
-In 2.4, the default will be to merge the tags. You can enable the old overwriting behavior via the config option.
-In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behaviour.
-
-
-Other caveats
--------------
-
-Here are some rare cases that might be encountered when updating. These are mostly caused by the more stringent parser validation and the capture of errors that were previously ignored.
-
-
-* Made ``any_errors_fatal`` inheritable from play to task and all other objects in between.
-
-Modules
-=======
-
-No major changes in this version.
-
-Modules removed
----------------
-
-No major changes in this version.
-
-Deprecation notices
--------------------
-
-The following modules will be removed in Ansible 2.5. Please update your playbooks accordingly.
-
-* ec2_vpc
-* cl_bond
-* cl_bridge
-* cl_img_install
-* cl_interface
-* cl_interface_policy
-* cl_license
-* cl_ports
-* nxos_mtu use :ref:`nxos_system <nxos_system_module>` instead
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel Ansible 2.3 Porting guide <https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.3.html>`_ for up to date information.
 
 .. note::
 
-    These modules may no longer have documentation in the current release.  Please see the
-    `Ansible 2.3 module documentation
-    <https://docs.ansible.com/ansible/2.3/list_of_all_modules.html>`_ if you need
-    to know how they worked for porting your playbooks.
-
-
-Noteworthy module changes
--------------------------
-
-AWS lambda
-^^^^^^^^^^
-Previously ignored changes that only affected one parameter. Existing deployments may have outstanding changes that this bug fix will apply.
-
-
-Mount
-^^^^^
-
-Mount: Some fixes so bind mounts are not mounted each time the playbook runs.
-
-
-Plugins
-=======
-
-No major changes in this version.
-
-Porting custom scripts
-======================
-
-No major changes in this version.
-
-Networking
-==========
-
-There have been a number of changes to number of changes to how Networking Modules operate.
-
-Playbooks should still use ``connection: local``.
-
-The following changes apply to:
-
-* dellos6
-* dellos9
-* dellos10
-* eos
-* ios
-* iosxr
-* junos
-* sros
-* vyos
-
-Deprecation of top-level connection arguments
----------------------------------------------
-
-**OLD** In Ansible 2.2:
-
-.. code-block:: guess
-
-    - name: example of using top-level options for connection properties
-      ios_command:
-        commands: show version
-        host: "{{ inventory_hostname }}"
-        username: cisco
-        password: cisco
-        authorize: yes
-        auth_pass: cisco
-
-Will result in:
-
-.. code-block:: guess
-
-   [WARNING]: argument username has been deprecated and will be removed in a future version
-   [WARNING]: argument host has been deprecated and will be removed in a future version
-   [WARNING]: argument password has been deprecated and will be removed in a future version
-
-
-**NEW** In Ansible 2.3:
-
-
-.. code-block:: guess
-
-   - name: Gather facts
-     eos_facts:
-       gather_subset: all
-       provider:
-         username: myuser
-         password: "{{ networkpassword }}"
-         transport: cli
-         host: "{{ ansible_host }}"
-
-delegate_to vs ProxyCommand
----------------------------
-
-The new connection framework for Network Modules in Ansible 2.3 that uses ``cli`` transport
-no longer supports the use of the ``delegate_to`` directive.
-In order to use a bastion or intermediate jump host to connect to network devices over ``cli``
-transport, network modules now support the use of ``ProxyCommand``.
-
-To use ``ProxyCommand`` configure the proxy settings in the Ansible inventory
-file to specify the proxy host via ``ansible_ssh_common_args``.
-
-For details on how to do this see the :ref:`network proxy guide <network_delegate_to_vs_ProxyCommand>`.
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.4.rst b/docs/docsite/rst/porting_guides/porting_guide_2.4.rst
index e77a3f5e35..eb2d9954fa 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_2.4.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_2.4.rst
@@ -1,226 +1,13 @@
+:orphan:
+
 .. _porting_2.4_guide:
 
 *************************
 Ansible 2.4 Porting Guide
 *************************
 
-This section discusses the behavioral changes between Ansible 2.3 and Ansible 2.4.
-
-It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
-
-
-We suggest you read this page along with `Ansible Changelog for 2.4 <https://github.com/ansible/ansible/blob/stable-2.4/CHANGELOG.md>`_ to understand what updates you may need to make.
-
-This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
-
-.. contents:: Topics
-
-Python version
-==============
-
-Ansible will not support Python 2.4 or 2.5 on the target hosts anymore. Going forward, Python 2.6+ will be required on targets, as already is the case on the controller.
-
-
-Inventory
-=========
-
-Inventory has been refactored to be implemented via plugins and now allows for multiple sources. This change is mostly transparent to users.
-
-One exception is the ``inventory_dir``, which is now a host variable; previously it could only have one value so it was set globally.
-This means you can no longer use it early in plays to determine ``hosts:`` or similar keywords.
-This also changes the behaviour of ``add_hosts`` and the implicit localhost;
-because they no longer automatically inherit the global value, they default to ``None``. See the module documentation for more information.
-
-The ``inventory_file`` remains mostly unchanged, as it was always host specific.
-
-Since there is no longer a single inventory, the 'implicit localhost' doesn't get either of these variables defined.
-
-A bug was fixed with the inventory path/directory, which was defaulting to the current working directory. This caused ``group_vars`` and ``host_vars`` to be picked up from the current working directory instead of just adjacent to the playbook or inventory directory when a host list (comma separated host names) was provided as inventory.
-
-Initial playbook relative group_vars and host_vars
---------------------------------------------------
-
-In Ansible versions prior to 2.4, the inventory system would maintain the context of the initial playbook that was executed. This allowed successively included playbooks from other directories to inherit group_vars and host_vars placed relative to the top level playbook file.
-
-Due to some behavioral inconsistencies, this functionality will not be included in the new
-inventory system starting with Ansible version 2.4.
-
-Similar functionality can still be achieved by using vars_files, include_vars, or group_vars and host_vars placed relative to the inventory file.
-
-Deprecated
-==========
-
-Specifying Inventory sources
------------------------------
-
-Use of ``--inventory-file`` on the command line is now deprecated. Use ``--inventory`` or ``-i``.
-The associated ini configuration key, ``hostfile``, and environment variable, ``ANSIBLE_HOSTS``,
-are also deprecated.  Replace them with the configuration key ``inventory`` and environment variable :envvar:`ANSIBLE_INVENTORY`.
-
-Use of multiple tags
---------------------
-
-Specifying ``--tags`` (or ``--skip-tags``) multiple times on the command line currently leads to the last one overriding all the previous ones. This behavior is deprecated. In the future, if you specify --tags multiple times the tags will be merged together. From now on, using ``--tags`` multiple times on one command line will emit a deprecation warning. Setting the ``merge_multiple_cli_tags`` option to True in the ``ansible.cfg`` file will enable the new behavior.
-
-In 2.4, the default has change to merge the tags. You can enable the old overwriting behavior via the config option.
-
-In 2.5, multiple ``--tags`` options will be merged with no way to go back to the old behavior.
-
-
-Other caveats
--------------
-
-No major changes in this version.
-
-Modules
-=======
-
-Major changes in popular modules are detailed here
-
-* The :ref:`win_shell <win_shell_module>` and :ref:`win_command <win_command_module>` modules now properly preserve quoted arguments in the command-line. Tasks that attempted to work around the issue by adding extra quotes/escaping may need to be reworked to remove the superfluous escaping. See `Issue 23019 <https://github.com/ansible/ansible/issues/23019>`_ for additional detail.
-
-Modules removed
----------------
-
-The following modules no longer exist:
-
-* None
-
-Deprecation notices
--------------------
-
-The following modules will be removed in Ansible 2.8. Please update your playbooks accordingly.
-
-* azure, use :ref:`azure_rm_virtualmachine <azure_rm_virtualmachine_module>`, which uses the new Resource Manager SDK.
-* win_msi, use :ref:`win_package <win_package_module>` instead
-
-Noteworthy module changes
--------------------------
-
-* The :ref:`win_get_url <win_get_url_module>`  module has the dictionary ``win_get_url`` in its results deprecated, its content is now also available directly in the resulting output, like other modules. This dictionary will be removed in Ansible 2.8.
-* The :ref:`win_unzip <win_unzip_module>` module no longer includes the dictionary ``win_unzip`` in its results; the contents are now included directly in the resulting output, like other modules.
-* The :ref:`win_package <win_package_module>` module return values ``exit_code`` and ``restart_required`` have been deprecated in favour of ``rc`` and ``reboot_required`` respectively. The deprecated return values will be removed in Ansible 2.6.
-
-
-Plugins
-=======
-
-A new way to configure and document plugins has been introduced.  This does not require changes to existing setups but developers should start adapting to the new infrastructure now. More details will be available in the developer documentation for each plugin type.
-
-Vars plugin changes
--------------------
-
-There have been many changes to the implementation of vars plugins, but both users and developers should not need to change anything to keep current setups working. Developers should consider changing their plugins take advantage of new features.
-
-The most notable difference to users is that vars plugins now get invoked on demand instead of at inventory build time.  This should make them more efficient for large inventories, especially when using a subset of the hosts.
-
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel Ansible 2.4 Porting guide <https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.4.html>`_ for up to date information.
 
 .. note::
-  - This also creates a difference with group/host_vars when using them adjacent to playbooks. Before, the 'first' playbook loaded determined the variables; now the 'current' playbook does. We are looking to fix this soon, since 'all playbooks' in the path should be considered for variable loading.
-  - In 2.4.1 we added a toggle to allow you to control this behaviour, 'top' will be the pre 2.4, 'bottom' will use the current playbook hosting the task and 'all' will use them all from top to bottom.
-
-
-Inventory plugins
------------------
-
-Developers should start migrating from hardcoded inventory with dynamic inventory scripts to the new Inventory Plugins. The scripts will still work via the ``script`` inventory plugin but Ansible development efforts will now concentrate on writing plugins rather than enhancing existing scripts.
-
-Both users and developers should look into the new plugins because they are intended to alleviate the need for many of the hacks and workarounds found in the dynamic inventory scripts.
-
-Callback plugins
-----------------
-
-Users:
-
-* Callbacks are now using the new configuration system.  Users should not need to change anything as the old system still works,
-  but you might see a deprecation notice if any callbacks used are not inheriting from the built in classes. Developers need to update them as stated below.
-
-Developers:
-
-* If your callback does not inherit from ``CallbackBase`` (directly or indirectly via another callback), it will still work, but issue a deprecation notice.
-  To avoid this and ensure it works in the future change it to inherit from ``CallbackBase`` so it has the new options handling methods and properties.
-  You can also implement the new options handling methods and properties but that won't automatically inherit changes added in the future.  You can look at ``CallbackBase`` itself and/or ``AnsiblePlugin`` for details.
-* Any callbacks inheriting from other callbacks might need to also be updated to contain the same documented options
-  as the parent or the options won't be available.  This is noted in the developer guide.
-
-Template lookup plugin: Escaping Strings
-----------------------------------------
-
-Prior to Ansible 2.4, backslashes in strings passed to the template lookup plugin would be escaped
-automatically. In 2.4, users are responsible for escaping backslashes themselves. This change
-brings the template lookup plugin inline with the template module so that the same backslash
-escaping rules apply to both.
-
-If you have a template lookup like this::
-
-    - debug:
-        msg: '{{ lookup("template", "template.j2") }}'
-
-**OLD** In Ansible 2.3 (and earlier) :file:`template.j2` would look like this:
-
-.. code-block:: jinja
-
-    {{ "name surname" | regex_replace("^[^\s]+\s+(.*)", "\1") }}
-
-**NEW** In Ansible 2.4 it should be changed to look like this:
-
-.. code-block:: jinja
-
-    {{ "name surname" | regex_replace("^[^\\s]+\\s+(.*)", "\\1") }}
-
-Tests
-=====
-
-Tests succeeded/failed
------------------------
-
-Prior to Ansible version 2.4, a task return code of ``rc`` would override a return code of ``failed``. In version 2.4,  both ``rc`` and ``failed`` are used to calculate the state of the task. Because of this, test plugins ``succeeded``/``failed``` have also been changed. This means that overriding a task failure with ``failed_when: no`` will result in ``succeeded``/``failed`` returning ``True``/``False``. For example::
-
-    - command: /bin/false
-      register: result
-      failed_when: no
-
-    - debug:
-        msg: 'This is printed on 2.3'
-      when: result|failed
-
-    - debug:
-        msg: 'This is printed on 2.4'
-      when: result|succeeded
-
-    - debug:
-        msg: 'This is always printed'
-      when: result.rc != 0
-
-As we can see from the example above, in Ansible 2.3 ``succeeded``/``failed`` only checked the value of ``rc``.
-
-Networking
-==========
-
-There have been a number of changes to how Networking Modules operate.
-
-Playbooks should still use ``connection: local``.
-
-Persistent Connection
----------------------
-
-The configuration variables ``connection_retries`` and ``connect_interval`` which were added in Ansible 2.3 are now deprecated. For Ansible 2.4 and later use ``connection_retry_timeout``.
-
-To control timeouts use ``command_timeout`` rather than the previous top level ``timeout`` variable under ``[default]``
-
-See :ref:`Ansible Network debug guide <network_debug_troubleshooting>` for more information.
-
-
-Configuration
-=============
-
-
-The configuration system has had some major changes. Users should be unaffected except for the following:
-
-* All relative paths defined are relative to the `ansible.cfg` file itself. Previously they varied by setting. The new behavior should be more predictable.
-* A new macro ``{{CWD}}`` is available for paths, which will make paths relative to the 'current working directory',
-  this is unsafe but some users really want to rely on this behaviour.
-
-Developers that were working directly with the previous API should revisit their usage as some methods (for example, ``get_config``) were  kept for backwards compatibility but will warn users that the function has been deprecated.
 
-The new configuration has been designed to minimize the need for code changes in core for new plugins.  The plugins just need to document their settings and the configuration system will use the documentation to provide what they need. This is still a work in progress; currently only 'callback' and 'connection' plugins support this.  More  details will be added to the specific plugin developer guides.
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst b/docs/docsite/rst/porting_guides/porting_guide_2.5.rst
index 6550ef68b5..439cbae060 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_2.5.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_2.5.rst
@@ -1,392 +1,13 @@
+:orphan:
+
 .. _porting_2.5_guide:
 
 *************************
 Ansible 2.5 Porting Guide
 *************************
 
-This section discusses the behavioral changes between Ansible 2.4 and Ansible 2.5.
-
-It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
-
-We suggest you read this page along with `Ansible Changelog for 2.5 <https://github.com/ansible/ansible/blob/stable-2.5/changelogs/CHANGELOG-v2.5.rst>`_ to understand what updates you may need to make.
-
-This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
-
-.. contents:: Topics
-
-Playbook
-========
-
-Dynamic includes and attribute inheritance
-------------------------------------------
-
-In Ansible version 2.4, the concept of dynamic includes (``include_tasks``) versus static imports (``import_tasks``) was introduced to clearly define the differences in how ``include`` works between dynamic and static includes.
-
-All attributes applied to a dynamic ``include_*`` would only apply to the include itself, while attributes applied to a
-static ``import_*`` would be inherited by the tasks within.
-
-This separation was only partially implemented in Ansible version 2.4. As of Ansible version 2.5, this work is complete and the separation now behaves as designed; attributes applied to an ``include_*`` task will not be inherited by the tasks within.
-
-To achieve an outcome similar to how Ansible worked prior to version 2.5, playbooks should use an explicit application of the attribute on the needed tasks, or use blocks to apply the attribute to many tasks. Another option is to use a static ``import_*`` when possible instead of a dynamic task.
-
-**OLD** In Ansible 2.4:
-
-.. code-block:: yaml
-
-    - include_tasks: "{{ ansible_distribution }}.yml"
-      tags:
-        - distro_include
-
-Included file:
-
-.. code-block:: yaml
-
-    - block:
-        - debug:
-            msg: "In included file"
-
-        - apt:
-            name: nginx
-            state: latest
-
-**NEW** In Ansible 2.5:
-
-Including task:
-
-.. code-block:: yaml
-
-    - include_tasks: "{{ ansible_distribution }}.yml"
-      tags:
-        - distro_include
-
-Included file:
-
-.. code-block:: yaml
-
-    - block:
-        - debug:
-            msg: "In included file"
-
-        - apt:
-            name: nginx
-            state: latest
-      tags:
-        - distro_include
-
-The relevant change in those examples is, that in Ansible 2.5, the included file defines the tag ``distro_include`` again. The tag is not inherited automatically.
-
-Fixed handling of keywords and inline variables
------------------------------------------------
-
-We made several fixes to how we handle keywords and 'inline variables', to avoid conflating the two. Unfortunately these changes mean you must specify whether `name` is a keyword or a variable when calling roles. If you have playbooks that look like this::
-
-    roles:
-        - { role: myrole, name: Justin, othervar: othervalue, become: True}
-
-You will run into errors because Ansible reads name in this context as a keyword. Beginning in 2.5, if you want to use a variable name that is also a keyword, you must explicitly declare it as a variable for the role::
-
-    roles:
-        - { role: myrole, vars: {name: Justin, othervar: othervalue}, become: True}
-
-
-For a full list of keywords see :ref:`playbook_keywords`.
-
-Migrating from with_X to loop
------------------------------
-
-.. include:: ../user_guide/shared_snippets/with2loop.txt
-
-
-Deprecated
-==========
-
-Jinja tests used as filters
----------------------------
-
-Using Ansible-provided jinja tests as filters will be removed in Ansible 2.9.
-
-Prior to Ansible 2.5, jinja tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` while jinja tests are referenced as ``variable is test_name``.
-
-Jinja tests are used for comparisons, while filters are used for data manipulation and have different applications in jinja. This change is to help differentiate the concepts for a better understanding of jinja, and where each can be appropriately used.
-
-As of Ansible 2.5, using an Ansible provided jinja test with filter syntax, will display a deprecation error.
-
-**OLD** In Ansible 2.4 (and earlier) the use of an Ansible included jinja test would likely look like this:
-
-.. code-block:: yaml
-
-    when:
-        - result | failed
-        - not result | success
-
-**NEW** In Ansible 2.5 it should be changed to look like this:
-
-.. code-block:: yaml
-
-    when:
-        - result is failed
-        - results is not successful
-
-In addition to the deprecation warnings, many new tests have been introduced that are aliases of the old tests. These new tests make more sense grammatically with the jinja test syntax, such as the new ``successful`` test which aliases ``success``.
-
-.. code-block:: yaml
-
-    when: result is successful
-
-See :ref:`playbooks_tests` for more information.
-
-Additionally, a script was created to assist in the conversion for tests using filter syntax to proper jinja test syntax. This script has been used to convert all of the Ansible integration tests to the correct format. There are a few limitations documented, and all changes made by this script should be evaluated for correctness before executing the modified playbooks. The script can be found at `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py <https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py>`_.
-
-Ansible fact namespacing
-------------------------
-
-Ansible facts, which have historically been written to names like ``ansible_*``
-in the main facts namespace, have been placed in their own new namespace,
-``ansible_facts.*`` For example, the fact ``ansible_distribution`` is now best
-queried through the variable structure ``ansible_facts.distribution``.
-
-A new configuration variable, ``inject_facts_as_vars``, has been added to
-ansible.cfg. Its default setting, 'True', keeps the 2.4 behavior of facts
-variables being set in the old ``ansible_*`` locations (while also writing them
-to the new namespace). This variable is expected to be set to 'False' in a
-future release. When ``inject_facts_as_vars`` is set to False, you must
-refer to ansible_facts through the new ``ansible_facts.*`` namespace.
-
-Modules
-=======
-
-Major changes in popular modules are detailed here.
-
-github_release
---------------
-
-In Ansible versions 2.4 and older, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module reported state as ``skipped``.
-In Ansible version 2.5 and later, after creating a GitHub release using the ``create_release`` state, the ``github_release`` module now reports state as ``changed``.
-
-
-Modules removed
----------------
-
-The following modules no longer exist:
-
-* nxos_mtu use :ref:`nxos_system <nxos_system_module>`'s ``system_mtu`` option or :ref:`nxos_interface <nxos_interface_module>` instead
-* cl_interface_policy use :ref:`nclu <nclu_module>` instead
-* cl_bridge use :ref:`nclu <nclu_module>` instead
-* cl_img_install use :ref:`nclu <nclu_module>` instead
-* cl_ports use :ref:`nclu <nclu_module>` instead
-* cl_license use :ref:`nclu <nclu_module>` instead
-* cl_interface use :ref:`nclu <nclu_module>` instead
-* cl_bond use :ref:`nclu <nclu_module>` instead
-* ec2_vpc use :ref:`ec2_vpc_net <ec2_vpc_net_module>` along with supporting modules :ref:`ec2_vpc_igw <ec2_vpc_igw_module>`, :ref:`ec2_vpc_route_table <ec2_vpc_route_table_module>`, :ref:`ec2_vpc_subnet <ec2_vpc_subnet_module>`, :ref:`ec2_vpc_dhcp_option <ec2_vpc_dhcp_option_module>`, :ref:`ec2_vpc_nat_gateway <ec2_vpc_nat_gateway_module>`, :ref:`ec2_vpc_nacl <ec2_vpc_nacl_module>` instead.
-* ec2_ami_search use :ref:`ec2_ami_facts <ec2_ami_facts_module>` instead
-* docker use :ref:`docker_container <docker_container_module>` and :ref:`docker_image <docker_image_module>` instead
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel Ansible 2.5 Porting guide <https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.5.html>`_ for up to date information.
 
 .. note::
 
-    These modules may no longer have documentation in the current release.  Please see the
-    `Ansible 2.4 module documentation
-    <https://docs.ansible.com/ansible/2.4/list_of_all_modules.html>`_ if you need
-    to know how they worked for porting your playbooks.
-
-
-
-Deprecation notices
--------------------
-
-The following modules will be removed in Ansible 2.9. Please update your playbooks accordingly.
-
-* Apstra's ``aos_*`` modules are deprecated as they do not work with AOS 2.1 or higher. See new modules at `https://github.com/apstra <https://github.com/apstra>`_.
-* nxos_ip_interface use :ref:`nxos_l3_interface <nxos_l3_interface_module>` instead.
-* nxos_portchannel use :ref:`nxos_linkagg <nxos_linkagg_module>` instead.
-* nxos_switchport use :ref:`nxos_l2_interface <nxos_l2_interface_module>` instead.
-* panos_security_policy use :ref:`panos_security_rule <panos_security_rule_module>` instead.
-* panos_nat_policy use :ref:`panos_nat_rule <panos_nat_rule_module>` instead.
-* vsphere_guest use :ref:`vmware_guest <vmware_guest_module>` instead.
-
-Noteworthy module changes
--------------------------
-
-* The :ref:`stat <stat_module>` and :ref:`win_stat <win_stat_module>` modules have changed the default of the option ``get_md5`` from ``true`` to ``false``.
-
-This option will be removed starting with Ansible version 2.9. The options ``get_checksum: True``
-and ``checksum_algorithm: md5`` can still be used if an MD5 checksum is
-desired.
-
-* ``osx_say`` module was renamed into :ref:`say <say_module>`.
-* Several modules which could deal with symlinks had the default value of their ``follow`` option
-  changed as part of a feature to `standardize the behavior of follow
-  <https://github.com/ansible/proposals/issues/69>`_:
-
-  * The :ref:`file module <file_module>` changed from ``follow=False`` to ``follow=True`` because
-    its purpose is to modify the attributes of a file and most systems do not allow attributes to be
-    applied to symlinks, only to real files.
-  * The :ref:`replace module <replace_module>` had its ``follow`` parameter removed because it
-    inherently modifies the content of an existing file so it makes no sense to operate on the link
-    itself.
-  * The :ref:`blockinfile module <blockinfile_module>` had its ``follow`` parameter removed because
-    it inherently modifies the content of an existing file so it makes no sense to operate on the
-    link itself.
-  * In Ansible-2.5.3, the :ref:`template module <template_module>` became more strict about its
-    ``src`` file being proper utf-8.  Previously, non-utf8 contents in a template module src file
-    would result in a mangled output file (the non-utf8 characters would be replaced with a unicode
-    replacement character).  Now, on Python2, the module will error out with the message, "Template
-    source files must be utf-8 encoded".  On Python3, the module will first attempt to pass the
-    non-utf8 characters through verbatim and fail if that does not succeed.
-
-Plugins
-=======
-
-As a developer, you can now use 'doc fragments' for common configuration options on plugin types that support the new plugin configuration system.
-
-Inventory
----------
-
-Inventory plugins have been fine tuned, and we have started to add some common features:
-
-* The ability to use a cache plugin to avoid costly API/DB queries is disabled by default.
-  If using inventory scripts, some may already support a cache, but it is outside of Ansible's knowledge and control.
-  Moving to the internal cache will allow you to use Ansible's existing cache refresh/invalidation mechanisms.
-
-* A new 'auto' plugin, enabled by default, that can automatically detect the correct plugin to use IF that plugin is using our 'common YAML configuration format'.
-  The previous host_list, script, yaml and ini plugins still work as they did, the auto plugin is now the last one we attempt to use.
-  If you had customized the enabled plugins you should revise the setting to include the new auto plugin.
-
-Shell
------
-
-Shell plugins have been migrated to the new plugin configuration framework. It is now possible to customize more settings, and settings which were previously 'global' can now also be overridden using host specific variables.
-
-For example, ``system_temps`` is a new setting that allows you to control what Ansible will consider a 'system temporary dir'. This is used when escalating privileges for a non-administrative user. Previously this was hardcoded to '/tmp', which some systems cannot use for privilege escalation. This setting now defaults to ``[ '/var/tmp', '/tmp']``.
-
-Another new setting is ``admin_users`` which allows you to specify a list of users to be considered 'administrators'. Previously this was hardcoded to ``root``. It now it defaults to ``[root, toor, admin]``.  This information is used when choosing between your ``remote_temp`` and ``system_temps`` directory.
-
-For a full list, check the shell plugin you are using, the default shell plugin is ``sh``.
-
-Those that had to work around the global configuration limitations can now migrate to a per host/group settings,
-but also note that the new defaults might conflict with existing usage if the assumptions don't correlate to your environment.
-
-Filter
-------
-
-The lookup plugin API now throws an error if a non-iterable value is returned from a plugin. Previously, numbers or
-other non-iterable types returned by a plugin were accepted without error or warning. This change was made because plugins should always return a list. Please note that plugins that return strings and other non-list iterable values will not throw an error, but may cause unpredictable behavior. If you have a custom lookup plugin that does not return a list, you should modify it to wrap the return values in a list.
-
-Lookup
--------
-
-A new option was added to lookup plugins globally named ``error`` which allows you to control how errors produced by the lookup are handled, before this option they were always fatal. Valid values for this option are ``warn``, ``ignore`` and ``strict``. See the :ref:`lookup <lookup_plugins>` page for more details.
-
-
-Porting custom scripts
-======================
-
-No notable changes.
-
-Network
-=======
-
-Expanding documentation
------------------------
-
-We're expanding the network documentation. There's new content and a :ref:`new Ansible Network landing page<network_guide>`. We will continue to build the network-related documentation moving forward.
-
-Top-level connection arguments will be removed in 2.9
------------------------------------------------------
-
-Top-level connection arguments like ``username``, ``host``, and ``password`` are deprecated and will be removed in version 2.9.
-
-**OLD** In Ansible < 2.4
-
-.. code-block:: yaml
-
-    - name: example of using top-level options for connection properties
-      ios_command:
-        commands: show version
-        host: "{{ inventory_hostname }}"
-        username: cisco
-        password: cisco
-        authorize: yes
-        auth_pass: cisco
-
-The deprecation warnings reflect this schedule. The task above, run in Ansible 2.5, will result in:
-
-.. code-block:: yaml
-
-   [DEPRECATION WARNING]: Param 'username' is deprecated. See the module docs for more information. This feature will be removed in version
-   2.9. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
-   [DEPRECATION WARNING]: Param 'password' is deprecated. See the module docs for more information. This feature will be removed in version
-   2.9. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
-   [DEPRECATION WARNING]: Param 'host' is deprecated. See the module docs for more information. This feature will be removed in version 2.9.
-   Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
-
-We recommend using the new connection types ``network_cli`` and ``netconf`` (see below), using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules<become_network>` guide and the :ref:`platform documentation<platform_options>`.
-
-Adding persistent connection types ``network_cli`` and ``netconf``
-------------------------------------------------------------------
-
-Ansible 2.5 introduces two top-level persistent connection types, ``network_cli`` and ``netconf``. With ``connection: local``, each task passed the connection parameters, which had to be stored in your playbooks. With ``network_cli`` and ``netconf`` the playbook passes the connection parameters once, so you can pass them at the command line if you prefer. We recommend you use ``network_cli`` and ``netconf`` whenever possible.
-Note that eAPI and NX-API still require ``local`` connections with ``provider`` dictionaries. See the :ref:`platform documentation<platform_options>` for more information. Unless you need a ``local`` connection, update your playbooks to use ``network_cli`` or ``netconf`` and to specify your connection variables with standard Ansible connection variables:
-
-**OLD** In Ansible 2.4
-
-.. code-block:: yaml
-
-   ---
-   vars:
-       cli:
-          host: "{{ inventory_hostname }}"
-          username: operator
-          password: secret
-          transport: cli
-
-   tasks:
-   - nxos_config:
-       src: config.j2
-       provider: "{{ cli }}"
-       username: admin
-       password: admin
-
-**NEW** In Ansible 2.5
-
-.. code-block:: ini
-
-   [nxos:vars]
-   ansible_connection=network_cli
-   ansible_network_os=nxos
-   ansible_user=operator
-   ansible_password=secret
-
-.. code-block:: yaml
-
-   tasks:
-   - nxos_config:
-       src: config.j2
-
-Using a provider dictionary with either ``network_cli`` or ``netconf`` will result in a warning.
-
-
-Developers: Shared Module Utilities Moved
------------------------------------------
-
-Beginning with Ansible 2.5, shared module utilities for network modules moved to ``ansible.module_utils.network``.
-
-* Platform-independent utilities are found in ``ansible.module_utils.network.common``
-
-* Platform-specific utilities are found in ``ansible.module_utils.network.{{ platform }}``
-
-If your module uses shared module utilities, you must update all references. For example, change:
-
-**OLD** In Ansible 2.4
-
-.. code-block:: python
-
-   from ansible.module_utils.vyos import get_config, load_config
-
-**NEW** In Ansible 2.5
-
-.. code-block:: python
-
-   from ansible.module_utils.network.vyos.vyos import get_config, load_config
-
-
-See the module utilities developer guide see :ref:`developing_module_utilities` for more information.
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.6.rst b/docs/docsite/rst/porting_guides/porting_guide_2.6.rst
index d585c00491..6150ccc940 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_2.6.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_2.6.rst
@@ -1,114 +1,13 @@
+:orphan:
+
 .. _porting_2.6_guide:
 
 *************************
 Ansible 2.6 Porting Guide
 *************************
 
-This section discusses the behavioral changes between Ansible 2.5 and Ansible 2.6.
-
-It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
-
-We suggest you read this page along with `Ansible Changelog for 2.6 <https://github.com/ansible/ansible/blob/stable-2.6/changelogs/CHANGELOG-v2.6.rst>`_ to understand what updates you may need to make.
-
-This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
-
-.. contents:: Topics
-
-Playbook
-========
-
-* The deprecated task option ``always_run`` has been removed, please use ``check_mode: no`` instead.
-
-Deprecated
-==========
-
-* In the :ref:`nxos_igmp_interface module<nxos_igmp_interface_module>`, ``oif_prefix`` and ``oif_source`` properties are deprecated. Use ``ois_ps`` parameter with a dictionary of prefix and source to values instead.
-
-Modules
-=======
-
-Major changes in popular modules are detailed here:
-
-
-Modules removed
----------------
-
-The following modules no longer exist:
-
-
-Deprecation notices
--------------------
-
-The following modules will be removed in Ansible 2.10. Please update your playbooks accordingly.
-
-* ``k8s_raw`` use :ref:`k8s <k8s_module>` instead.
-* ``openshift_raw`` use :ref:`k8s <k8s_module>` instead.
-* ``openshift_scale`` use :ref:`k8s_scale <k8s_scale_module>` instead.
-
-Noteworthy module changes
--------------------------
-
-* The ``upgrade`` module option for ``win_chocolatey`` has been removed; use ``state: latest`` instead.
-* The ``reboot`` module option for ``win_feature`` has been removed; use the ``win_reboot`` action plugin instead.
-* The ``win_iis_webapppool`` module no longer accepts a string for the ``attributes`` module option; use the free form dictionary value instead.
-* The ``name`` module option for ``win_package`` has been removed; this is not used anywhere and should just be removed from your playbooks.
-* The ``win_regedit`` module no longer automatically corrects the hive path ``HCCC`` to ``HKCC``; use ``HKCC`` because this is the correct hive path.
-* The :ref:`file_module` now emits a deprecation warning when ``src`` is specified with a state
-  other than ``hard`` or ``link`` as it is only supposed to be useful with those.  This could have
-  an effect on people who were depending on a buggy interaction between src and other state's to
-  place files into a subdirectory.  For instance::
-
-    $ ansible localhost -m file -a 'path=/var/lib src=/tmp/ state=directory'
-
-  Would create a directory named ``/tmp/lib``.  Instead of the above, simply spell out the entire
-  destination path like this::
-
-    $ ansible localhost -m file -a 'path=/tmp/lib state=directory'
-
-* The ``k8s_raw`` and ``openshift_raw`` modules have been aliased to the new ``k8s`` module.
-* The ``k8s`` module supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources.
-* The ``k8s`` module will not accept resources where subkeys have been snake_cased. This was a workaround that was suggested with the ``k8s_raw`` and ``openshift_raw`` modules.
-* The ``k8s`` module may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource.
-* The ``k8s`` module can now process multi-document YAML files if they are passed with the ``src`` parameter. It will process each document as a separate resource. Resources provided inline with the ``resource_definition`` parameter must still be a single document.
-* The ``k8s`` module will not automatically change ``Project`` creation requests into ``ProjectRequest`` creation requests as the ``openshift_raw`` module did. You must now specify the ``ProjectRequest`` kind explicitly.
-* The ``k8s`` module will not automatically remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block.
-* The ``k8s_scale`` module now supports scalable OpenShift objects, such as ``DeploymentConfig``.
-* The ``lineinfile`` module was changed to show a warning when using an empty string as a regexp.
-  Since an empty regexp matches every line in a file, it will replace the last line in a file rather
-  than inserting. If this is the desired behavior, use ``'^'`` which will match every line and
-  will not trigger the warning.
-* Openstack modules are no longer using ``shade`` library. Instead ``openstacksdk`` is used. Since ``openstacksdk`` should be already present as a dependency to ``shade`` no additional actions are required.
-
-Plugins
-=======
-
-Deprecation notices
--------------------
-
-The following modules will be removed in Ansible 2.10. Please update your playbooks accordingly.
-
-* ``openshift`` use ``k8s`` instead.
-
-
-Noteworthy plugin changes
--------------------------
-
-* The ``k8s`` lookup plugin now supports all Kubernetes resources including those from Custom Resource Definitions and aggregated API servers. This includes all OpenShift resources.
-* The ``k8s`` lookup plugin may not accept resources where the ``api_version`` has been changed to match the shortened version in the Kubernetes Python client. You should now specify the proper full Kubernetes ``api_version`` for a resource.
-* The ``k8s`` lookup plugin will no longer remove secrets from the Ansible return values (and by extension the log). In order to prevent secret values in a task from being logged, specify the ``no_log`` parameter on the task block.
-
-
-Porting custom scripts
-======================
-
-No notable changes.
-
-Networking
-==========
-
-No notable changes.
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel Ansible 2.6 Porting guide <https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.6.html>`_ for up to date information.
 
-Dynamic inventory scripts
-=========================
+.. note::
 
-* ``contrib/inventory/openstack.py`` has been renamed to ``contrib/inventory/openstack_inventory.py``. If you have used ``openstack.py`` as a name for your OpenStack dynamic inventory file, change it to ``openstack_inventory.py``. Otherwise the file name will conflict with imports from ``openstacksdk``.
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.7.rst b/docs/docsite/rst/porting_guides/porting_guide_2.7.rst
index 816f77bc5c..2da9785eb6 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_2.7.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_2.7.rst
@@ -1,262 +1,13 @@
+:orphan:
+
 .. _porting_2.7_guide:
 
 *************************
 Ansible 2.7 Porting Guide
 *************************
 
-This section discusses the behavioral changes between Ansible 2.6 and Ansible 2.7.
-
-It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
-
-We suggest you read this page along with `Ansible Changelog for 2.7 <https://github.com/ansible/ansible/blob/stable-2.7/changelogs/CHANGELOG-v2.7.rst>`_ to understand what updates you may need to make.
-
-This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
-
-.. contents:: Topics
-
-Command Line
-============
-
-If you specify ``--tags`` or ``--skip-tags`` multiple times on the command line, Ansible will merge the specified
-tags together.  In previous versions of Ansible, you could set ``merge_multiple_cli_tags`` to ``False``
-if you wanted to keep only the last-specified ``--tags``.  This config
-option existed for backwards compatibility. The overwriting behavior was deprecated in 2.3 and
-the default behavior was changed in 2.4.  Ansible-2.7 removes the config option; multiple
-``--tags`` are now always merged.
-
-If you have a shell script that depends on setting ``merge_multiple_cli_tags`` to ``False``, please upgrade your script
-so it only adds the ``--tags`` you actually want before upgrading to Ansible-2.7.
-
-
-Python Compatibility
-====================
-
-Ansible has dropped compatibility with Python-2.6 on the controller (The host where :command:`/usr/bin/ansible`
-or :command:`/usr/bin/ansible-playbook` is run).  Modules shipped with Ansible can still be used to
-manage hosts which only have Python-2.6.  You just need to have a host with Python-2.7 or Python-3.5
-or greater to manage those hosts from.
-
-One thing that this does affect is the ability to use :command:`/usr/bin/ansible-pull` to manage
-a host which has Python-2.6.  ``ansible-pull`` runs on the host being managed but it is a controller
-script, not a module so it will need an updated Python.  Actively developed Linux distros which ship
-with Python-2.6 have some means to install newer Python versions (For instance, you can install
-Python-2.7 via an SCL on RHEL-6) but you may need to also install Python bindings for many common
-modules to work (For RHEL-6, for instance, selinux bindings and yum would have to be installed for
-the updated Python install).
-
-The decision to drop Python-2.6 support on the controller was made because many dependent libraries
-are becoming unavailable there.  In particular, python-cryptography is no longer available for Python-2.6
-and the last release of pycrypto (the alternative to python-cryptography) has known security bugs
-which will never be fixed.
-
-
-Playbook
-========
-
-Role Precedence Fix during Role Loading
----------------------------------------
-
-Ansible 2.7 makes a small change to variable precedence when loading roles, resolving a bug, ensuring that role loading matches :ref:`variable precedence expectations <ansible_variable_precedence>`.
-
-Before Ansible 2.7, when loading a role, the variables defined in the role's ``vars/main.yml`` and ``defaults/main.yml`` were not available when parsing the role's ``tasks/main.yml`` file. This prevented the role from utilizing these variables when being parsed. The problem manifested when ``import_tasks`` or ``import_role`` was used with a variable defined in the role's vars or defaults.
-
-In Ansible 2.7, role ``vars`` and ``defaults`` are now parsed before ``tasks/main.yml``. This can cause a change in behavior if the same variable is defined at the play level and the role level with different values, and leveraged in ``import_tasks`` or ``import_role`` to define the role or file to import.
-
-include_role and import_role variable exposure
-----------------------------------------------
-
-In Ansible 2.7 a new module argument named ``public`` was added to the ``include_role`` module that dictates whether or not the role's ``defaults`` and ``vars`` will be exposed outside of the role, allowing those variables to be used by later tasks.  This value defaults to ``public: False``, matching current behavior.
-
-``import_role`` does not support the ``public`` argument, and will unconditionally expose the role's ``defaults`` and ``vars`` to the rest of the playbook. This functionality brings ``import_role`` into closer alignment with roles listed within the ``roles`` header in a play.
-
-There is an important difference in the way that ``include_role`` (dynamic) will expose the role's variables, as opposed to ``import_role`` (static). ``import_role`` is a pre-processor, and the ``defaults`` and ``vars`` are evaluated at playbook parsing, making the variables available to tasks and roles listed at any point in the play. ``include_role`` is a conditional task, and the ``defaults`` and ``vars`` are evaluated at execution time, making the variables available to tasks and roles listed *after* the ``include_role`` task.
-
-include_tasks/import_tasks inline variables
--------------------------------------------
-
-As of Ansible 2.7, `include_tasks` and `import_tasks` can no longer accept inline variables. Instead of using inline variables, tasks should supply variables under the ``vars`` keyword.
-
-**OLD** In Ansible 2.6 (and earlier) the following was valid syntax for specifying variables:
-
-.. code-block:: yaml
-
-    - include_tasks: include_me.yml variable=value
-
-**NEW** In Ansible 2.7 the task should be changed to use the ``vars`` keyword:
-
-.. code-block:: yaml
-
-    - include_tasks: include_me.yml
-      vars:
-        variable: value
-
-vars_prompt with unknown algorithms
------------------------------------
-
-vars_prompt now throws an error if the hash algorithm specified in encrypt is not supported by
-the controller.  This increases the safety of vars_prompt as it previously returned None if the
-algorithm was unknown.  Some modules, notably the user module, treated a password of None as
-a request not to set a password.  If your playbook starts erroring because of this, change the
-hashing algorithm being used with this filter.
-
-
-Deprecated
-==========
-
-Expedited Deprecation: Removal of the params module option in ``ldap_attr`` and ``ldap_entry``
-----------------------------------------------------------------------------------------------
-
-The ``params`` module option in ``ldap_attr`` and ``ldap_entry`` are deprecated on a short cycle (to
-be removed in Ansible-2.10) due to circumventing Ansible's normal option handling.  In particular,
-if the ``bind_pw`` option is set with ``params``, the value of the option could end up being placed
-in a logfile or displayed on stdout.
-
-
-Expedited Deprecation: Use of ``__file__`` in ``AnsibleModule``
----------------------------------------------------------------
-
-.. note:: The use of the ``__file__`` variable is deprecated in Ansible 2.7 and **will be eliminated in Ansible 2.8**. This is much quicker than our usual 4-release deprecation cycle.
-
-We are deprecating the use of the ``__file__`` variable to refer to the file containing the currently-running code. This common Python technique for finding a filesystem path does not always work (even in vanilla Python). Sometimes a Python module can be imported from a virtual location (like inside of a zip file). When this happens, the ``__file__`` variable will reference a virtual location pointing to inside of the zip file. This can cause problems if, for instance, the code was trying to use ``__file__`` to find the directory containing the python module to write some temporary information.
-
-Before the introduction of AnsiBallZ in Ansible 2.1, using ``__file__`` worked in ``AnsibleModule`` sometimes, but any module that used it would fail when pipelining was turned on (because the module would be piped into the python interpreter's standard input, so ``__file__`` wouldn't contain a file path). AnsiBallZ unintentionally made using ``__file__`` work, by always creating a temporary file for ``AnsibleModule`` to reside in.
-
-Ansible 2.8 will no longer create a temporary file for ``AnsibleModule``; instead it will read the file out of a zip file. This change should speed up module execution, but it does mean that starting with Ansible 2.8, referencing ``__file__`` will always fail in ``AnsibleModule``.
-
-If you are the author of a third-party module which uses ``__file__`` with ``AnsibleModule``, please update your module(s) now, while the use of ``__file__`` is deprecated but still available. The most common use of ``__file__`` is to find a directory to write a temporary file. In Ansible 2.5 and above, you can use the ``tmpdir`` attribute on an ``AnsibleModule`` instance instead, as shown in this code from the :ref:`apt module <apt_module>`:
-
-.. code-block:: diff
-
-    -    tempdir = os.path.dirname(__file__)
-    -    package = os.path.join(tempdir, to_native(deb.rsplit('/', 1)[1]))
-    +    package = os.path.join(module.tmpdir, to_native(deb.rsplit('/', 1)[1]))
-
-
-Using a loop on a package module via squash_actions
----------------------------------------------------
-
-The use of ``squash_actions`` to invoke a package module, such as "yum", to only invoke the module once is deprecated, and will be removed in Ansible 2.11.
-
-Instead of relying on implicit squashing, tasks should instead supply the list directly to the ``name``, ``pkg`` or ``package`` parameter of the module. This functionality has been supported in most modules since Ansible 2.3.
-
-**OLD** In Ansible 2.6 (and earlier) the following task would invoke the "yum" module only 1 time to install multiple packages
-
-.. code-block:: yaml
-
-    - name: Install packages
-      yum:
-        name: "{{ item }}"
-        state: present
-      with_items: "{{ packages }}"
-
-**NEW** In Ansible 2.7 it should be changed to look like this:
-
-.. code-block:: yaml
-
-    - name: Install packages
-      yum:
-        name: "{{ packages }}"
-        state: present
-
-
-Modules
-=======
-
-Major changes in popular modules are detailed here
-
-* The :ref:`DEFAULT_SYSLOG_FACILITY` configuration option tells Ansible modules to use a specific
-  `syslog facility <https://en.wikipedia.org/wiki/Syslog#Facility>`_ when logging information on all
-  managed machines. Due to a bug with older Ansible versions, this setting did not affect machines
-  using journald with the systemd Python bindings installed. On those machines, Ansible log
-  messages were sent to ``/var/log/messages``, even if you set :ref:`DEFAULT_SYSLOG_FACILITY`.
-  Ansible 2.7 fixes this bug, routing all Ansible log messages according to the value set for
-  :ref:`DEFAULT_SYSLOG_FACILITY`. If you have :ref:`DEFAULT_SYSLOG_FACILITY` configured, the
-  location of remote logs on systems which use journald may change.
-
-Modules removed
----------------
-
-The following modules no longer exist:
-
-
-Deprecation notices
--------------------
-
-The following modules will be removed in Ansible 2.11. Please update your playbooks accordingly.
-
-* ``na_cdot_aggregate`` use :ref:`na_ontap_aggregate <na_ontap_aggregate_module>` instead.
-* ``na_cdot_license`` use :ref:`na_ontap_license <na_ontap_license_module>` instead.
-* ``na_cdot_lun`` use :ref:`na_ontap_lun <na_ontap_lun_module>` instead.
-* ``na_cdot_qtree`` use :ref:`na_ontap_qtree <na_ontap_qtree_module>` instead.
-* ``na_cdot_svm`` use :ref:`na_ontap_svm <na_ontap_svm_module>` instead.
-* ``na_cdot_user`` use :ref:`na_ontap_user <na_ontap_user_module>` instead.
-* ``na_cdot_user_role`` use :ref:`na_ontap_user_role <na_ontap_user_role_module>` instead.
-* ``na_cdot_volume`` use :ref:`na_ontap_volume <na_ontap_volume_module>` instead.
-* ``sf_account_manager`` use :ref:`na_elementsw_account<na_elementsw_account_module>` instead.
-* ``sf_check_connections`` use :ref:`na_elementsw_check_connections<na_elementsw_check_connections_module>` instead.
-* ``sf_snapshot_schedule_manager`` use :ref:`na_elementsw_snapshot_schedule<na_elementsw_snapshot_schedule_module>` instead.
-* ``sf_volume_access_group_manager`` use :ref:`na_elementsw_access_group<na_elementsw_access_group_module>` instead.
-* ``sf_volume_manager`` use :ref:`na_elementsw_volume<na_elementsw_volume_module>` instead.
-
-Noteworthy module changes
--------------------------
-
-* **Security Issue** Setting ``bind_pw`` with the ``params`` option for the ``ldap_entry`` and
-  ``ldap_attr`` modules has been disallowed.  If ``bind_pw`` was set with ``params``, the value
-  could have ended up in a logfile or displayed on stdout.  Set ``bind_pw`` directly, with the
-  modules' options instead.
-
-* Check mode is now supported in the ``command`` and ``shell`` modules. However, only when ``creates`` or ``removes`` is
-  specified. If either of these are specified, the module will check for existence of the file and report the correct
-  changed status, if they are not included the module will skip like it had done previously.
-
-* The ``win_chocolatey`` module originally required the ``proxy_username`` and ``proxy_password`` to
-  escape any double quotes in the value. This is no longer required and the escaping may cause further
-  issues.
-
-* The ``win_uri`` module has removed the deprecated option ``use_basic_parsing``, since Ansible 2.5 this option did
-  nothing
-
-* The ``win_scheduled_task`` module has removed the following deprecated options:
-
-  * ``executable``, use ``path`` in an actions entry instead
-  * ``argument``, use ``arguments`` in an actions entry instead
-  * ``store_password``, set ``logon_type: password`` instead
-  * ``days_of_week``, use ``monthlydow`` in a triggers entry instead
-  * ``frequency``, use ``type``, in a triggers entry instead
-  * ``time``, use ``start_boundary`` in a triggers entry instead
-
-* The ``interface_name`` module option for ``na_ontap_net_vlan`` has been removed and should be removed from your playbooks
-
-* The ``win_disk_image`` module has deprecated the return value ``mount_path``, use ``mount_paths[0]`` instead. This will
-  be removed in Ansible 2.11.
-
-* ``include_role`` and ``include_tasks`` can now be used directly from ``ansible`` (adhoc) and ``ansible-console``::
-
-    #> ansible -m include_role -a 'name=myrole' all
-
-* The ``pip`` module has added a dependency on ``setuptools`` to support version requirements, this requirement is for
-  the Python interpreter that executes the module and not the Python interpreter that the module is managing.
-
-* Prior to Ansible 2.7.10, the ``replace`` module did the opposite of what was intended when using the ``before`` and ``after`` options together. This now works properly but may require changes to tasks.
-
-
-Plugins
-=======
-
-* The hash_password filter now throws an error if the hash algorithm specified is not supported by
-  the controller.  This increases the safety of the filter as it previously returned None if the
-  algorithm was unknown.  Some modules, notably the user module, treated a password of None as
-  a request not to set a password.  If your playbook starts erroring because of this, change the
-  hashing algorithm being used with this filter.
-
-
-Porting custom scripts
-======================
-
-No notable changes.
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel Ansible 2.7 Porting guide <https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.7.html>`_ for up to date information.
 
-Networking
-==========
+.. note::
 
-No notable changes.
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.8.rst b/docs/docsite/rst/porting_guides/porting_guide_2.8.rst
index 4b695e63eb..56fb2db323 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_2.8.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_2.8.rst
@@ -1,589 +1,13 @@
+:orphan:
+
 .. _porting_2.8_guide:
 
 *************************
 Ansible 2.8 Porting Guide
 *************************
 
-This section discusses the behavioral changes between Ansible 2.7 and Ansible 2.8.
-
-It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
-
-We suggest you read this page along with `Ansible Changelog for 2.8 <https://github.com/ansible/ansible/blob/stable-2.8/changelogs/CHANGELOG-v2.8.rst>`_ to understand what updates you may need to make.
-
-This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
-
-.. contents::
-   :local:
-
-Playbook
-========
-
-Distribution Facts
-------------------
-
-The information returned for the ``ansible_distribution_*`` group of facts may have changed
-slightly.  Ansible 2.8 uses a new backend library for information about distributions: `nir0s/distro <https://github.com/nir0s/distro>`_. This library runs on Python-3.8 and fixes many bugs, including correcting release and version names.
-
-The two facts used in playbooks most often, ``ansible_distribution`` and ``ansible_distribution_major_version``, should not change. If you discover a change in these facts, please file a bug so we can address the
-difference.  However, other facts like ``ansible_distribution_release`` and
-``ansible_distribution_version`` may change as erroneous information gets corrected.
-
-Imports as handlers
--------------------
-
-Beginning in version 2.8, a task cannot notify ``import_tasks`` or a static ``include`` that is specified in ``handlers``.
-
-The goal of a static import is to act as a pre-processor, where the import is replaced by the tasks defined within the imported file. When
-using an import, a task can notify any of the named tasks within the imported file, but not the name of the import itself.
-
-To achieve the results of notifying a single name but running multiple handlers, utilize ``include_tasks``, or ``listen`` :ref:`handlers`.
-
-Jinja Undefined values
-----------------------
-
-Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use
-a default with a value in a nested data structure when you don't know if the intermediate values are defined.
-
-In Ansible 2.8::
-
-    {{ foo.bar.baz | default('DEFAULT') }}
-
-In Ansible 2.7 and older::
-
-    {{ ((foo | default({})).bar | default({})).baz | default('DEFAULT') }}
-
-    or
-
-    {{ foo.bar.baz if (foo is defined and foo.bar is defined and foo.bar.baz is defined) else 'DEFAULT' }}
-
-Module option conversion to string
-----------------------------------
-
-Beginning in version 2.8, Ansible will warn if a module expects a string, but a non-string value is passed and automatically converted to a string. This highlights potential problems where, for example, a ``yes`` or ``true`` (parsed as truish boolean value) would be converted to the string ``'True'``, or where a version number ``1.10`` (parsed as float value) would be converted to ``'1.1'``. Such conversions can result in unexpected behavior depending on context.
-
-This behavior can be changed to be an error or to be ignored by setting the ``ANSIBLE_STRING_CONVERSION_ACTION`` environment variable, or by setting the ``string_conversion_action`` configuration in the ``defaults`` section of ``ansible.cfg``.
-
-Command line facts
-------------------
-
-``cmdline`` facts returned in system will be deprecated in favor of ``proc_cmdline``. This change handles special case where Kernel command line parameter contains multiple values with the same key.
-
-Bare variables in conditionals
-------------------------------
-
-In Ansible 2.7 and earlier, top-level variables sometimes treated boolean strings as if they were boolean values. This led to inconsistent behavior in conditional tests built on top-level variables defined as strings. Ansible 2.8 began changing this behavior. For example, if you set two conditions like this:
-
-.. code-block:: yaml
-
-   tasks:
-     - include_tasks: teardown.yml
-       when: teardown
-
-     - include_tasks: provision.yml
-       when: not teardown
-
-based on a variable you define **as a string** (with quotation marks around it):
-
-* In Ansible 2.7 and earlier, the two conditions above evaluated as ``True`` and ``False`` respectively if ``teardown: 'true'``
-* In Ansible 2.7 and earlier, both conditions evaluated as ``False`` if ``teardown: 'false'``
-* In Ansible 2.8 and later, you have the option of disabling conditional bare variables, so ``when: teardown`` always evaluates as ``True`` and ``when: not teardown`` always evaluates as ``False`` when ``teardown`` is a non-empty string (including ``'true'`` or ``'false'``)
-
-Ultimately, ``when: 'string'`` will always evaluate as ``True`` and ``when: not 'string'`` will always evaluate as ``False``, as long as ``'string'`` is not empty, even if the value of ``'string'`` itself looks like a boolean. For users with playbooks that depend on the old behavior, we added a config setting that preserves it. You can use the ``ANSIBLE_CONDITIONAL_BARE_VARS`` environment variable or ``conditional_bare_variables`` in the ``defaults`` section of ``ansible.cfg`` to select the behavior you want on your control node. The default setting is ``true``, which preserves the old behavior. Set the config value or environment variable to ``false`` to start using the new option.
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel Ansible 2.8 Porting guide <https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.8.html>`_ for up to date information.
 
 .. note::
 
-   In 2.10 the default setting for ``conditional_bare_variables`` will change to ``false``. In 2.12 the old behavior will be deprecated.
-
-Updating your playbooks
-^^^^^^^^^^^^^^^^^^^^^^^
-
-To prepare your playbooks for the new behavior, you must update your conditional statements so they accept only boolean values. For variables, you can use the ``bool`` filter to evaluate the string ``'false'`` as ``False``:
-
-.. code-block:: yaml
-
-    vars:
-      teardown: 'false'
-
-    tasks:
-      - include_tasks: teardown.yml
-        when: teardown | bool
-
-      - include_tasks: provision.yml
-        when: not teardown | bool
-
-Alternatively, you can re-define your variables as boolean values (without quotation marks) instead of strings:
-
-.. code-block:: yaml
-
-            vars:
-              teardown: false
-
-            tasks:
-              - include_tasks: teardown.yml
-                when: teardown
-
-              - include_tasks: provision.yml
-                when: not teardown
-
-For dictionaries and lists, use the ``length`` filter to evaluate the presence of a dictionary or list as ``True``:
-
-.. code-block:: yaml+jinja
-
-      - debug:
-        when: my_list | length > 0
-
-      - debug:
-        when: my_dictionary | length > 0
-
-Do not use the ``bool`` filter with lists or dictionaries. If you use ``bool`` with a list or dict, Ansible will always evaluate it as ``False``.
-
-Double-interpolation
-^^^^^^^^^^^^^^^^^^^^
-
-The ``conditional_bare_variables`` setting also affects variables set based on other variables. The old behavior unexpectedly double-interpolated those variables. For example:
-
-.. code-block:: yaml
-
-    vars:
-      double_interpolated: 'bare_variable'
-      bare_variable: false
-
-    tasks:
-      - debug:
-        when: double_interpolated
-
-* In Ansible 2.7 and earlier, ``when: double_interpolated`` evaluated to the value of ``bare_variable``, in this case, ``False``. If the variable ``bare_variable`` is undefined, the conditional fails.
-* In Ansible 2.8 and later, with bare variables disabled, Ansible evaluates ``double_interpolated`` as the string ``'bare_variable'``, which is ``True``.
-
-To double-interpolate variable values, use curly braces:
-
-.. code-block:: yaml+jinja
-
-    vars:
-      double_interpolated: "{{ other_variable }}"
-      other_variable: false
-
-Nested variables
-^^^^^^^^^^^^^^^^
-
-The ``conditional_bare_variables`` setting does not affect nested variables. Any string value assigned to a subkey is already respected and not treated as a boolean. If ``complex_variable['subkey']`` is a non-empty string, then ``when: complex_variable['subkey']`` is always ``True`` and ``when: not complex_variable['subkey']`` is always ``False``. If you want a string subkey like ``complex_variable['subkey']`` to be evaluated as a boolean, you must use the ``bool`` filter.
-
-Gathering Facts
----------------
-
-In Ansible 2.8 the implicit "Gathering Facts" task in a play was changed to
-obey play tags. Previous to 2.8, the "Gathering Facts" task would ignore play
-tags and tags supplied from the command line and always run in a task.
-
-The behavior change affects the following example play.
-
-.. code-block:: yaml
-
-    - name: Configure Webservers
-      hosts: webserver
-      tags:
-        - webserver
-      tasks:
-        - name: Install nginx
-          package:
-            name: nginx
-          tags:
-            - nginx
-
-In Ansible 2.8, if you supply ``--tags nginx``, the implicit
-"Gathering Facts" task will be skipped, as the task now inherits
-the tag of ``webserver`` instead of ``always``.
-
-If no play level tags are set, the "Gathering Facts" task will
-be given a tag of ``always`` and will effectively match prior
-behavior.
-
-You can achieve similar results to the pre-2.8 behavior, by
-using an explicit ``gather_facts`` task in your ``tasks`` list.
-
-.. code-block:: yaml
-
-    - name: Configure Webservers
-      hosts: webserver
-      gather_facts: false
-      tags:
-        - webserver
-      tasks:
-        - name: Gathering Facts
-          gather_facts:
-          tags:
-            - always
-
-        - name: Install nginx
-          package:
-            name: nginx
-          tags:
-            - nginx
-
-Python Interpreter Discovery
-============================
-
-In Ansible 2.7 and earlier, Ansible defaulted to :command:`/usr/bin/python` as the
-setting for ``ansible_python_interpreter``. If you ran Ansible against a system
-that installed Python with a different name or a different path, your playbooks
-would fail with ``/usr/bin/python: bad interpreter: No such file or directory``
-unless you either set ``ansible_python_interpreter`` to the correct value for
-that system or added a Python interpreter and any necessary dependencies at
-:command:`usr/bin/python`.
-
-Starting in Ansible 2.8, Ansible searches for the correct path and executable
-name for Python on each target system, first in a lookup table of default
-Python interpreters for common distros, then in an ordered fallback list of
-possible Python interpreter names/paths.
-
-It's risky to rely on a Python interpreter set from the fallback list, because
-the interpreter may change on future runs. If an interpreter from
-higher in the fallback list gets installed (for example, as a side-effect of
-installing other packages), your original interpreter and its dependencies will
-no longer be used. For this reason, Ansible warns you when it uses a Python
-interpreter discovered from the fallback list. If you see this warning, the
-best solution is to explicitly set ``ansible_python_interpreter`` to the path
-of the correct interpreter for those target systems.
-
-You can still set ``ansible_python_interpreter`` to a specific path at any
-variable level (as a host variable, in vars files, in playbooks, etc.).
-If you prefer to use the Python interpreter discovery behavior, use
-one of the four new values for ``ansible_python_interpreter`` introduced in
-Ansible 2.8:
-
-+---------------------------+---------------------------------------------+
-| New value                 | Behavior                                    |
-+===========================+=============================================+
-| auto |br|                 | If a Python interpreter is discovered,      |
-| (future default)          | Ansible uses the discovered Python, even if |
-|                           | :command:`/usr/bin/python` is also present. |
-|                           | Warns when using the fallback list.         |
-+---------------------------+---------------------------------------------+
-| **auto_legacy** |br|      | If a Python interpreter is discovered, and  |
-| (Ansible 2.8 default)     | :command:`/usr/bin/python` is absent,       |
-|                           | Ansible uses the discovered Python. Warns   |
-|                           | when using the fallback list.               |
-|                           |                                             |
-|                           | If a Python interpreter is discovered, and  |
-|                           | :command:`/usr/bin/python` is present,      |
-|                           | Ansible uses :command:`/usr/bin/python` and |
-|                           | prints a deprecation warning about future   |
-|                           | default behavior. Warns when using the      |
-|                           | fallback list.                              |
-+---------------------------+---------------------------------------------+
-| auto_legacy_silent        | Behaves like ``auto_legacy`` but suppresses |
-|                           | the deprecation and fallback-list warnings. |
-+---------------------------+---------------------------------------------+
-| auto_silent               | Behaves like ``auto`` but suppresses the    |
-|                           | fallback-list warning.                      |
-+---------------------------+---------------------------------------------+
-
-
-In Ansible 2.12, Ansible will switch the default from :literal:`auto_legacy` to :literal:`auto`.
-The difference in behaviour is that :literal:`auto_legacy` uses :command:`/usr/bin/python` if
-present and falls back to the discovered Python when it is not present.  :literal:`auto` will always
-use the discovered Python, regardless of whether :command:`/usr/bin/python` exists.  The
-:literal:`auto_legacy` setting provides compatibility with previous versions of Ansible that always
-defaulted to :command:`/usr/bin/python`.
-
-If you installed Python and dependencies (``boto``, etc.) to
-:command:`/usr/bin/python` as a workaround on distros with a different default Python
-interpreter (for example, Ubuntu 16.04+, RHEL8, Fedora 23+), you have two
-options:
-
-  #. Move existing dependencies over to the default Python for each platform/distribution/version.
-  #. Use ``auto_legacy``. This setting lets Ansible find and use the workaround Python on hosts that have it, while also finding the correct default Python on newer hosts. But remember, the default will change in 4 releases.
-
-
-Retry File Creation default
----------------------------
-
-In Ansible 2.8, ``retry_files_enabled`` now defaults to ``False`` instead of ``True``.  The behavior can be
-modified to previous version by editing the default ``ansible.cfg`` file and setting the value to ``True``.
-
-Command Line
-============
-
-Become Prompting
-----------------
-
-Beginning in version 2.8, by default Ansible will use the word ``BECOME`` to prompt you for a password for elevated privileges (``sudo`` privileges on Unix systems or ``enable`` mode on network devices):
-
-By default in Ansible 2.8::
-
-    ansible-playbook --become --ask-become-pass site.yml
-    BECOME password:
-
-If you want the prompt to display the specific ``become_method`` you're using, instead of the agnostic value ``BECOME``, set :ref:`AGNOSTIC_BECOME_PROMPT` to ``False`` in your Ansible configuration.
-
-By default in Ansible 2.7, or with ``AGNOSTIC_BECOME_PROMPT=False`` in Ansible 2.8::
-
-    ansible-playbook --become --ask-become-pass site.yml
-    SUDO password:
-
-Deprecated
-==========
-
-* The ``params`` module option in ``ldap_attr`` and ``ldap_entry`` are deprecated on a short cycle
-  (to be removed in Ansible-2.10) due to circumventing Ansible's normal option handling.  In
-  particular, if the ``bind_pw`` option is set with ``params``, the value of the option could end up
-  being placed in a logfile or displayed on stdout.
-
-* Setting the async directory using ``ANSIBLE_ASYNC_DIR`` as an task/play environment key is deprecated and will be
-  removed in Ansible 2.12. You can achieve the same result by setting ``ansible_async_dir`` as a variable like::
-
-      - name: run task with custom async directory
-        command: sleep 5
-        async: 10
-        vars:
-          ansible_async_dir: /tmp/.ansible_async
-
-* Plugin writers who need a ``FactCache`` object should be aware of two deprecations:
-
-  1. The ``FactCache`` class has moved from ``ansible.plugins.cache.FactCache`` to
-     ``ansible.vars.fact_cache.FactCache``.  This is because the ``FactCache`` is not part of the
-     cache plugin API and cache plugin authors should not be subclassing it.  ``FactCache`` is still
-     available from its old location but will issue a deprecation warning when used from there.  The
-     old location will be removed in Ansible 2.12.
-
-  2. The ``FactCache.update()`` method has been converted to follow the dict API.  It now takes a
-     dictionary as its sole argument and updates itself with the dictionary's items.  The previous
-     API where ``update()`` took a key and a value will now issue a deprecation warning and will be
-     removed in 2.12.  If you need the old behavior switch to ``FactCache.first_order_merge()``
-     instead.
-
-* Supporting file-backed caching via self.cache is deprecated and will
-  be removed in Ansible 2.12. If you maintain an inventory plugin, update it to use ``self._cache`` as a dictionary. For implementation details, see
-  the :ref:`developer guide on inventory plugins<inventory_plugin_caching>`.
-
-* Importing cache plugins directly is deprecated and will be removed in Ansible 2.12. Use the plugin_loader
-  so direct options, environment variables, and other means of configuration can be reconciled using the config
-  system rather than constants.
-
-  .. code-block:: python
-
-     from ansible.plugins.loader import cache_loader
-     cache = cache_loader.get('redis', **kwargs)
-
-Modules
-=======
-
-Major changes in popular modules are detailed here
-
-The exec wrapper that runs PowerShell modules has been changed to set ``$ErrorActionPreference = "Stop"`` globally.
-This may mean that custom modules can fail if they implicitly relied on this behavior. To get the old behavior back,
-add ``$ErrorActionPreference = "Continue"`` to the top of the module. This change was made to restore the old behavior
-of the EAP that was accidentally removed in a previous release and ensure that modules are more resilient to errors
-that may occur in execution.
-
-* Version 2.8.14 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the ``mode`` change has been reverted in 2.8.15, and ``mode`` will now default to ``0o666 & ~umask`` as in previous versions of Ansible.
-* If you changed any tasks to specify less restrictive permissions while using 2.8.14, those changes will be unnecessary (but will do no harm) in 2.8.15.
-* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it.
-
-
-Modules removed
----------------
-
-The following modules no longer exist:
-
-* ec2_remote_facts
-* azure
-* cs_nic
-* netscaler
-* win_msi
-
-Deprecation notices
--------------------
-
-The following modules will be removed in Ansible 2.12. Please update your playbooks accordingly.
-
-* ``foreman`` use `foreman-ansible-modules <https://github.com/theforeman/foreman-ansible-modules>`_ instead.
-* ``katello`` use `foreman-ansible-modules <https://github.com/theforeman/foreman-ansible-modules>`_ instead.
-* ``github_hooks`` use :ref:`github_webhook <github_webhook_module>` and :ref:`github_webhook_facts <github_webhook_facts_module>` instead.
-* ``digital_ocean`` use :ref:`digital_ocean_droplet <digital_ocean_droplet_module>` instead.
-* ``gce`` use :ref:`gcp_compute_instance <gcp_compute_instance_module>` instead.
-* ``gcspanner`` use :ref:`gcp_spanner_instance <gcp_spanner_instance_module>` and :ref:`gcp_spanner_database <gcp_spanner_database_module>` instead.
-* ``gcdns_record`` use :ref:`gcp_dns_resource_record_set <gcp_dns_resource_record_set_module>` instead.
-* ``gcdns_zone`` use :ref:`gcp_dns_managed_zone <gcp_dns_managed_zone_module>` instead.
-* ``gcp_forwarding_rule`` use :ref:`gcp_compute_global_forwarding_rule <gcp_compute_global_forwarding_rule_module>` or :ref:`gcp_compute_forwarding_rule <gcp_compute_forwarding_rule_module>` instead.
-* ``gcp_healthcheck`` use :ref:`gcp_compute_health_check <gcp_compute_health_check_module>`, :ref:`gcp_compute_http_health_check <gcp_compute_http_health_check_module>`, or :ref:`gcp_compute_https_health_check <gcp_compute_https_health_check_module>` instead.
-* ``gcp_backend_service`` use :ref:`gcp_compute_backend_service <gcp_compute_backend_service_module>` instead.
-* ``gcp_target_proxy`` use :ref:`gcp_compute_target_http_proxy <gcp_compute_target_http_proxy_module>` instead.
-* ``gcp_url_map`` use :ref:`gcp_compute_url_map <gcp_compute_url_map_module>` instead.
-* ``panos`` use the `Palo Alto Networks Ansible Galaxy role <https://galaxy.ansible.com/PaloAltoNetworks/paloaltonetworks>`_ instead.
-
-
-Noteworthy module changes
--------------------------
-
-* **Security Issue** Setting ``bind_pw`` with the ``params`` option for the ``ldap_entry`` and
-  ``ldap_attr`` modules has been disallowed.  If ``bind_pw`` was set with ``params``, the value
-  could have ended up in a logfile or displayed on stdout.  Set ``bind_pw`` directly, with the
-  modules' options instead.
-* The ``foreman`` and ``katello`` modules have been deprecated in favor of a set of modules that are broken out per entity with better idempotency in mind.
-* The ``foreman`` and ``katello`` modules replacement is officially part of the Foreman Community and supported there.
-* The ``tower_credential`` module originally required the ``ssh_key_data`` to be the path to a ssh_key_file.
-  In order to work like Tower/AWX, ``ssh_key_data`` now contains the content of the file.
-  The previous behavior can be achieved with ``lookup('file', '/path/to/file')``.
-* The ``win_scheduled_task`` module deprecated support for specifying a trigger repetition as a list and this format
-  will be removed in Ansible 2.12. Instead specify the repetition as a dictionary value.
-
-* The ``win_feature`` module has removed the deprecated ``restart_needed`` return value, use the standardized
-  ``reboot_required`` value instead.
-
-* The ``win_package`` module has removed the deprecated ``restart_required`` and ``exit_code`` return value, use the
-  standardized ``reboot_required`` and ``rc`` value instead.
-
-* The ``win_get_url`` module has removed the deprecated ``win_get_url`` return dictionary, contained values are
-  returned directly.
-
-* The ``win_get_url`` module has removed the deprecated ``skip_certificate_validation`` option, use the standardized
-  ``validate_certs`` option instead.
-
-* The ``vmware_local_role_facts`` module now returns a list of dicts instead of a dict of dicts for role information.
-
-* If ``docker_network`` or ``docker_volume`` were called with ``diff: yes``, ``check_mode: yes`` or ``debug: yes``,
-  a return value called ``diff`` was returned of type ``list``. To enable proper diff output, this was changed to
-  type ``dict``; the original ``list`` is returned as ``diff.differences``.
-
-* The ``na_ontap_cluster_peer`` module has replaced ``source_intercluster_lif`` and ``dest_intercluster_lif`` string options with
-  ``source_intercluster_lifs`` and ``dest_intercluster_lifs`` list options
-
-* The ``modprobe`` module now detects kernel builtins. Previously, attempting to remove (with ``state: absent``)
-  a builtin kernel module succeeded without any error message because ``modprobe`` did not detect the module as
-  ``present``. Now, ``modprobe`` will fail if a kernel module is builtin and ``state: absent`` (with an error message
-  from the modprobe binary like ``modprobe: ERROR: Module nfs is builtin.``), and it will succeed without reporting
-  changed if ``state: present``. Any playbooks that are using ``changed_when: no`` to mask this quirk can safely
-  remove that workaround. To get the previous behavior when applying ``state: absent`` to a builtin kernel module,
-  use ``failed_when: false`` or ``ignore_errors: true`` in your playbook.
-
-* The ``digital_ocean`` module has been deprecated in favor of modules that do not require external dependencies.
-  This allows for more flexibility and better module support.
-
-* The ``docker_container`` module has deprecated the returned fact ``docker_container``. The same value is
-  available as the returned variable ``container``. The returned fact will be removed in Ansible 2.12.
-* The ``docker_network`` module has deprecated the returned fact ``docker_container``. The same value is
-  available as the returned variable ``network``. The returned fact will be removed in Ansible 2.12.
-* The ``docker_volume`` module has deprecated the returned fact ``docker_container``. The same value is
-  available as the returned variable ``volume``. The returned fact will be removed in Ansible 2.12.
-
-* The ``docker_service`` module was renamed to :ref:`docker_compose <docker_compose_module>`.
-* The renamed ``docker_compose`` module used to return one fact per service, named same as the service. A dictionary
-  of these facts is returned as the regular return value ``services``. The returned facts will be removed in
-  Ansible 2.12.
-
-* The ``docker_swarm_service`` module no longer sets a defaults for the following options:
-    * ``user``. Before, the default was ``root``.
-    * ``update_delay``. Before, the default was ``10``.
-    * ``update_parallelism``. Before, the default was ``1``.
-
-* ``vmware_vm_facts`` used to return dict of dict with virtual machine's facts. Ansible 2.8 and onwards will return list of dict with virtual machine's facts.
-  Please see module ``vmware_vm_facts`` documentation for example.
-
-* ``vmware_guest_snapshot`` module used to return ``results``. Since Ansible 2.8 and onwards ``results`` is a reserved keyword, it is replaced by ``snapshot_results``.
-  Please see module ``vmware_guest_snapshots`` documentation for example.
-
-* The ``panos`` modules have been deprecated in favor of using the Palo Alto Networks `Ansible Galaxy role
-  <https://galaxy.ansible.com/PaloAltoNetworks/paloaltonetworks>`_.  Contributions to the role can be made
-  `here <https://github.com/PaloAltoNetworks/ansible-pan>`_.
-
-* The ``ipa_user`` module originally always sent ``password`` to FreeIPA regardless of whether the password changed. Now the module only sends ``password`` if ``update_password`` is set to ``always``, which is the default.
-
-* The ``win_psexec`` has deprecated the undocumented ``extra_opts`` module option. This will be removed in Ansible 2.10.
-
-* The ``win_nssm`` module has deprecated the following options in favor of using the ``win_service`` module to configure the service after installing it with ``win_nssm``:
-  * ``dependencies``, use ``dependencies`` of ``win_service`` instead
-  * ``start_mode``, use ``start_mode`` of ``win_service`` instead
-  * ``user``, use ``username`` of ``win_service`` instead
-  * ``password``, use ``password`` of ``win_service`` instead
-  These options will be removed in Ansible 2.12.
-
-* The ``win_nssm`` module has also deprecated the ``start``, ``stop``, and ``restart`` values of the ``status`` option.
-  You should use the ``win_service`` module to control the running state of the service. This will be removed in Ansible 2.12.
-
-* The ``status`` module option for ``win_nssm`` has changed its default value to ``present``. Before, the default was ``start``.
-  Consequently, the service is no longer started by default after creation with ``win_nssm``, and you should use
-  the ``win_service`` module to start it if needed.
-
-* The ``app_parameters`` module option for ``win_nssm`` has been deprecated; use ``argument`` instead. This will be removed in Ansible 2.12.
-
-* The ``app_parameters_free_form`` module option for ``win_nssm`` has been aliased to the new ``arguments`` option.
-
-* The ``win_dsc`` module will now validate the input options for a DSC resource. In previous versions invalid options
-  would be ignored but are now not.
-
-* The ``openssl_pkcs12`` module will now regenerate the pkcs12 file if there are differences between the file on disk and the parameters passed to the module.
-
-Plugins
-=======
-
-* Ansible no longer defaults to the ``paramiko`` connection plugin when using macOS as the control node. Ansible will now use the ``ssh`` connection plugin by default on a macOS control node.  Since ``ssh`` supports connection persistence between tasks and playbook runs, it performs better than ``paramiko``. If you are using password authentication, you will need to install ``sshpass`` when using the ``ssh`` connection plugin. Or you can explicitly set the connection type to ``paramiko`` to maintain the pre-2.8 behavior on macOS.
-
-* Connection plugins have been standardized to allow use of ``ansible_<conn-type>_user``
-  and ``ansible_<conn-type>_password`` variables.  Variables such as
-  ``ansible_<conn-type>_pass`` and ``ansible_<conn-type>_username`` are treated
-  with lower priority than the standardized names and may be deprecated in the
-  future.  In general, the ``ansible_user`` and ``ansible_password`` vars should
-  be used unless there is a reason to use the connection-specific variables.
-
-* The ``powershell`` shell plugin now uses ``async_dir`` to define the async path for the results file and the default
-  has changed to ``%USERPROFILE%\.ansible_async``. To control this path now, either set the ``ansible_async_dir``
-  variable or the ``async_dir`` value in the ``powershell`` section of the config ini.
-
-* Order of enabled inventory plugins (:ref:`INVENTORY_ENABLED`) has been updated, :ref:`auto <auto_inventory>` is now before :ref:`yaml <yaml_inventory>` and :ref:`ini <ini_inventory>`.
-
-* The private ``_options`` attribute has been removed from the ``CallbackBase`` class of callback
-  plugins.  If you have a third-party callback plugin which needs to access the command line arguments,
-  use code like the following instead of trying to use ``self._options``:
-
-  .. code-block:: python
-
-     from ansible import context
-     [...]
-     tags = context.CLIARGS['tags']
-
-  ``context.CLIARGS`` is a read-only dictionary so normal dictionary retrieval methods like
-  ``CLIARGS.get('tags')`` and ``CLIARGS['tags']`` work as expected but you won't be able to modify
-  the cli arguments at all.
-
-* Play recap now counts ``ignored`` and ``rescued`` tasks as well as ``ok``, ``changed``, ``unreachable``, ``failed`` and ``skipped`` tasks, thanks to two additional stat counters in the ``default`` callback plugin. Tasks that fail and have ``ignore_errors: yes`` set are listed as ``ignored``. Tasks that fail and then execute a rescue section are listed as ``rescued``. Note that ``rescued`` tasks are no longer counted as ``failed`` as in Ansible 2.7 (and earlier).
-
-* ``osx_say`` callback plugin was renamed into :ref:`say <say_callback>`.
-
-* Inventory plugins now support caching via cache plugins. To start using a cache plugin with your inventory see the section on caching in the :ref:`inventory guide<using_inventory>`. To port a custom cache plugin to be compatible with inventory see :ref:`developer guide on cache plugins<developing_cache_plugins>`.
-
-Porting custom scripts
-======================
-
-Display class
--------------
-
-As of Ansible 2.8, the ``Display`` class is now a "singleton". Instead of using ``__main__.display`` each file should
-import and instantiate ``ansible.utils.display.Display`` on its own.
-
-**OLD** In Ansible 2.7 (and earlier) the following was used to access the ``display`` object:
-
-.. code-block:: python
-
-   try:
-       from __main__ import display
-   except ImportError:
-       from ansible.utils.display import Display
-       display = Display()
-
-**NEW** In Ansible 2.8 the following should be used:
-
-.. code-block:: python
-
-   from ansible.utils.display import Display
-   display = Display()
-
-Networking
-==========
-
-* The ``eos_config``, ``ios_config``, and ``nxos_config`` modules have removed the deprecated
-  ``save`` and ``force`` parameters, use the ``save_when`` parameter to replicate their
-  functionality.
-
-* The ``nxos_vrf_af`` module has removed the ``safi`` parameter. This parameter was deprecated
-  in Ansible 2.4 and has had no impact on the module since then.
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
diff --git a/docs/docsite/rst/porting_guides/porting_guide_2.9.rst b/docs/docsite/rst/porting_guides/porting_guide_2.9.rst
index 770c9f11c9..997423132c 100644
--- a/docs/docsite/rst/porting_guides/porting_guide_2.9.rst
+++ b/docs/docsite/rst/porting_guides/porting_guide_2.9.rst
@@ -1,3 +1,4 @@
+:orphan:
 
 .. _porting_2.9_guide:
 
@@ -5,761 +6,8 @@
 Ansible 2.9 Porting Guide
 *************************
 
-This section discusses the behavioral changes between Ansible 2.8 and Ansible 2.9.
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel Ansible 2.9 Porting guide <https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.9.html>`_ for up to date information.
 
-It is intended to assist in updating your playbooks, plugins and other parts of your Ansible infrastructure so they will work with this version of Ansible.
+.. note::
 
-We suggest you read this page along with `Ansible Changelog for 2.9 <https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst>`_ to understand what updates you may need to make.
-
-This document is part of a collection on porting. The complete list of porting guides can be found at :ref:`porting guides <porting_guides>`.
-
-.. contents:: Topics
-
-
-Playbook
-========
-
-Inventory
----------
-
- * ``hash_behaviour`` now affects inventory sources. If you have it set to ``merge``, the data you get from inventory might change and you will have to update playbooks accordingly. If you're using the default setting (``overwrite``), you will see no changes. Inventory was ignoring this setting.
-
-Loops
------
-
-Ansible 2.9 handles "unsafe" data more robustly, ensuring that data marked "unsafe" is not templated. In previous versions, Ansible recursively marked all data returned by the direct use of ``lookup()`` as "unsafe", but only marked structured data returned by indirect lookups using ``with_X`` style loops as "unsafe" if the returned elements were strings. Ansible 2.9 treats these two approaches consistently.
-
-As a result, if you use ``with_dict`` to return keys with templatable values, your templates may no longer work as expected in Ansible 2.9.
-
-To allow the old behavior, switch from using ``with_X`` to using ``loop`` with a filter as described at :ref:`migrating_to_loop`.
-
-Command Line
-============
-
-* The location of the Galaxy token file has changed from ``~/.ansible_galaxy`` to ``~/.ansible/galaxy_token``. You can configure both path and file name with the :ref:`galaxy_token_path` config.
-
-
-Deprecated
-==========
-
-- The ``params`` module option in ``ldap_attr`` and ``ldap_entry`` are deprecated on a short cycle (to be
-  removed in Ansible-2.10) due to circumventing Ansible's normal option handling.  In particular, if
-  the ``bind_pw`` option is set with ``params``, the value of the option could end up being placed in
-  a logfile or displayed on stdout.
-
-
-Collection loader changes
-=========================
-
-The way to import a PowerShell or C# module util from a collection has changed in the Ansible 2.9 release. In Ansible
-2.8 a util was imported with the following syntax:
-
-.. code-block:: powershell
-
-    #AnsibleRequires -CSharpUtil AnsibleCollections.namespace_name.collection_name.util_filename
-    #AnsibleRequires -PowerShell AnsibleCollections.namespace_name.collection_name.util_filename
-
-In Ansible 2.9 this was changed to:
-
-.. code-block:: powershell
-
-    #AnsibleRequires -CSharpUtil ansible_collections.namespace_name.collection_name.plugins.module_utils.util_filename
-    #AnsibleRequires -PowerShell ansible_collections.namespace_name.collection_name.plugins.module_utils.util_filename
-
-The change in the collection import name also requires any C# util namespaces to be updated with the newer name
-format. This is more verbose but is designed to make sure we avoid plugin name conflicts across separate plugin types
-and to standardise how imports work in PowerShell with how Python modules work.
-
-
-Modules
-=======
-
-* The ``win_get_url`` and ``win_uri`` module now sends requests with a default ``User-Agent`` of ``ansible-httpget``. This can be changed by using the ``http_agent`` key.
-* The ``apt`` module now honors ``update_cache=false`` while installing its own dependency and skips the cache update. Explicitly setting ``update_cache=true`` or omitting the param ``update_cache`` will result in a cache update while installing its own dependency.
-
-* Version 2.9.12 of Ansible changed the default mode of file-based tasks to ``0o600 & ~umask`` when the user did not specify a ``mode`` parameter on file-based tasks. This was in response to a CVE report which we have reconsidered. As a result, the mode change has been reverted in 2.9.13, and mode will now default to ``0o666 & ~umask`` as in previous versions of Ansible.
-* If you changed any tasks to specify less restrictive permissions while using 2.9.12, those changes will be unnecessary (but will do no harm) in 2.9.13.
-* To avoid the issue raised in CVE-2020-1736, specify a ``mode`` parameter in all file-based tasks that accept it.
-
-
-Renaming from ``_facts`` to ``_info``
---------------------------------------
-
-Ansible 2.9 renamed a lot of modules from ``<something>_facts`` to ``<something>_info``, because the modules do not return :ref:`Ansible facts <vars_and_facts>`. Ansible facts relate to a specific host. For example, the configuration of a network interface, the operating system on a unix server, and the list of packages installed on a Windows box are all Ansible facts. The renamed modules return values that are not unique to the host. For example, account information or region data for a cloud provider. Renaming these modules should provide more clarity about the types of return values each set of modules offers.
-
-Writing modules
----------------
-
-* Module and module_utils files can now use relative imports to include other module_utils files.
-  This is useful for shortening long import lines, especially in collections.
-
-  Example of using a relative import in collections:
-
-  .. code-block:: python
-
-    # File: ansible_collections/my_namespace/my_collection/plugins/modules/my_module.py
-    # Old way to use an absolute import to import module_utils from the collection:
-    from ansible_collections.my_namespace.my_collection.plugins.module_utils import my_util
-    # New way using a relative import:
-    from ..module_utils import my_util
-
-  Modules and module_utils shipped with Ansible can use relative imports as well but the savings
-  are smaller:
-
-  .. code-block:: python
-
-    # File: ansible/modules/system/ping.py
-    # Old way to use an absolute import to import module_utils from core:
-    from ansible.module_utils.basic import AnsibleModule
-    # New way using a relative import:
-    from ...module_utils.basic import AnsibleModule
-
-  Each single dot (``.``) represents one level of the tree (equivalent to ``../`` in filesystem relative links).
-
-  .. seealso:: `The Python Relative Import Docs <https://www.python.org/dev/peps/pep-0328/#guido-s-decision>`_ go into more detail of how to write relative imports.
-
-
-Modules removed
----------------
-
-The following modules no longer exist:
-
-* Apstra's ``aos_*`` modules.  See the new modules at  `https://github.com/apstra <https://github.com/apstra>`_.
-* ec2_ami_find use :ref:`ec2_ami_facts <ec2_ami_facts_module>` instead.
-* kubernetes use :ref:`k8s_raw <k8s_raw_module>` instead.
-* nxos_ip_interface use :ref:`nxos_l3_interface <nxos_l3_interface_module>` instead.
-* nxos_portchannel use :ref:`nxos_linkagg <nxos_linkagg_module>` instead.
-* nxos_switchport use :ref:`nxos_l2_interface <nxos_l2_interface_module>` instead.
-* oc use :ref:`openshift_raw <openshift_raw_module>` instead.
-* panos_nat_policy use :ref:`panos_nat_rule <panos_nat_rule_module>` instead.
-* panos_security_policy use :ref:`panos_security_rule <panos_security_rule_module>` instead.
-* vsphere_guest use :ref:`vmware_guest <vmware_guest_module>` instead.
-
-
-Deprecation notices
--------------------
-
-The following modules will be removed in Ansible 2.13. Please update update your playbooks accordingly.
-
-* cs_instance_facts use :ref:`cs_instance_info <cs_instance_info_module>` instead.
-
-* cs_zone_facts use :ref:`cs_zone_info <cs_zone_info_module>` instead.
-
-* digital_ocean_sshkey_facts use :ref:`digital_ocean_sshkey_info <digital_ocean_sshkey_info_module>` instead.
-
-* eos_interface use :ref:`eos_interfaces <eos_interfaces_module>` instead.
-
-* eos_l2_interface use :ref:`eos_l2_interfaces <eos_l2_interfaces_module>` instead.
-
-* eos_l3_interface use :ref:`eos_l3_interfaces <eos_l3_interfaces_module>` instead.
-
-* eos_linkagg use :ref:`eos_lag_interfaces <eos_lag_interfaces_module>` instead.
-
-* eos_lldp_interface use :ref:`eos_lldp_interfaces <eos_lldp_interfaces_module>` instead.
-
-* eos_vlan use :ref:`eos_vlans <eos_vlans_module>` instead.
-
-* ios_interface use :ref:`ios_interfaces <ios_interfaces_module>` instead.
-
-* ios_l2_interface use :ref:`ios_l2_interfaces <ios_l2_interfaces_module>` instead.
-
-* ios_l3_interface use :ref:`ios_l3_interfaces <ios_l3_interfaces_module>` instead.
-
-* ios_vlan use :ref:`ios_vlans <ios_vlans_module>` instead.
-
-* iosxr_interface use :ref:`iosxr_interfaces <iosxr_interfaces_module>` instead.
-
-* junos_interface use :ref:`junos_interfaces <junos_interfaces_module>` instead.
-
-* junos_l2_interface use :ref:`junos_l2_interfaces <junos_l2_interfaces_module>` instead.
-
-* junos_l3_interface use :ref:`junos_l3_interfaces <junos_l3_interfaces_module>` instead.
-
-* junos_linkagg use :ref:`junos_lag_interfaces <junos_lag_interfaces_module>` instead.
-
-* junos_lldp use :ref:`junos_lldp_global <junos_lldp_global_module>` instead.
-
-* junos_lldp_interface use :ref:`junos_lldp_interfaces <junos_lldp_interfaces_module>` instead.
-
-* junos_vlan use :ref:`junos_vlans <junos_vlans_module>` instead.
-
-* lambda_facts use :ref:`lambda_info <lambda_info_module>` instead.
-
-* na_ontap_gather_facts use :ref:`na_ontap_info <na_ontap_info_module>` instead.
-
-* net_banner use the platform-specific [netos]_banner modules instead.
-
-* net_interface use the new platform-specific [netos]_interfaces modules instead.
-
-* net_l2_interface use the new platform-specific [netos]_l2_interfaces modules instead.
-
-* net_l3_interface use the new platform-specific [netos]_l3_interfaces modules instead.
-
-* net_linkagg use the new platform-specific [netos]_lag modules instead.
-
-* net_lldp use the new platform-specific [netos]_lldp_global modules instead.
-
-* net_lldp_interface use the new platform-specific [netos]_lldp_interfaces modules instead.
-
-* net_logging use the platform-specific [netos]_logging modules instead.
-
-* net_static_route use the platform-specific [netos]_static_route modules instead.
-
-* net_system use the platform-specific [netos]_system modules instead.
-
-* net_user use the platform-specific [netos]_user modules instead.
-
-* net_vlan use the new platform-specific [netos]_vlans modules instead.
-
-* net_vrf use the platform-specific [netos]_vrf modules instead.
-
-* nginx_status_facts use :ref:`nginx_status_info <nginx_status_info_module>` instead.
-
-* nxos_interface use :ref:`nxos_interfaces <nxos_interfaces_module>` instead.
-
-* nxos_l2_interface use :ref:`nxos_l2_interfaces <nxos_l2_interfaces_module>` instead.
-
-* nxos_l3_interface use :ref:`nxos_l3_interfaces <nxos_l3_interfaces_module>` instead.
-
-* nxos_linkagg use :ref:`nxos_lag_interfaces <nxos_lag_interfaces_module>` instead.
-
-* nxos_vlan use :ref:`nxos_vlans <nxos_vlans_module>` instead.
-
-* online_server_facts use :ref:`online_server_info <online_server_info_module>` instead.
-
-* online_user_facts use :ref:`online_user_info <online_user_info_module>` instead.
-
-* purefa_facts use :ref:`purefa_info <purefa_info_module>` instead.
-
-* purefb_facts use :ref:`purefb_info <purefb_info_module>` instead.
-
-* scaleway_image_facts use :ref:`scaleway_image_info <scaleway_image_info_module>` instead.
-
-* scaleway_ip_facts use :ref:`scaleway_ip_info <scaleway_ip_info_module>` instead.
-
-* scaleway_organization_facts use :ref:`scaleway_organization_info <scaleway_organization_info_module>` instead.
-
-* scaleway_security_group_facts use :ref:`scaleway_security_group_info <scaleway_security_group_info_module>` instead.
-
-* scaleway_server_facts use :ref:`scaleway_server_info <scaleway_server_info_module>` instead.
-
-* scaleway_snapshot_facts use :ref:`scaleway_snapshot_info <scaleway_snapshot_info_module>` instead.
-
-* scaleway_volume_facts use :ref:`scaleway_volume_info <scaleway_volume_info_module>` instead.
-
-* vcenter_extension_facts use :ref:`vcenter_extension_info <vcenter_extension_info_module>` instead.
-
-* vmware_about_facts use :ref:`vmware_about_info <vmware_about_info_module>` instead.
-
-* vmware_category_facts use :ref:`vmware_category_info <vmware_category_info_module>` instead.
-
-* vmware_drs_group_facts use :ref:`vmware_drs_group_info <vmware_drs_group_info_module>` instead.
-
-* vmware_drs_rule_facts use :ref:`vmware_drs_rule_info <vmware_drs_rule_info_module>` instead.
-
-* vmware_dvs_portgroup_facts use :ref:`vmware_dvs_portgroup_info <vmware_dvs_portgroup_info_module>` instead.
-
-* vmware_guest_boot_facts use :ref:`vmware_guest_boot_info <vmware_guest_boot_info_module>` instead.
-
-* vmware_guest_customization_facts use :ref:`vmware_guest_customization_info <vmware_guest_customization_info_module>` instead.
-
-* vmware_guest_disk_facts use :ref:`vmware_guest_disk_info <vmware_guest_disk_info_module>` instead.
-
-* vmware_host_capability_facts use :ref:`vmware_host_capability_info <vmware_host_capability_info_module>` instead.
-
-* vmware_host_config_facts use :ref:`vmware_host_config_info <vmware_host_config_info_module>` instead.
-
-* vmware_host_dns_facts use :ref:`vmware_host_dns_info <vmware_host_dns_info_module>` instead.
-
-* vmware_host_feature_facts use :ref:`vmware_host_feature_info <vmware_host_feature_info_module>` instead.
-
-* vmware_host_firewall_facts use :ref:`vmware_host_firewall_info <vmware_host_firewall_info_module>` instead.
-
-* vmware_host_ntp_facts use :ref:`vmware_host_ntp_info <vmware_host_ntp_info_module>` instead.
-
-* vmware_host_package_facts use :ref:`vmware_host_package_info <vmware_host_package_info_module>` instead.
-
-* vmware_host_service_facts use :ref:`vmware_host_service_info <vmware_host_service_info_module>` instead.
-
-* vmware_host_ssl_facts use :ref:`vmware_host_ssl_info <vmware_host_ssl_info_module>` instead.
-
-* vmware_host_vmhba_facts use :ref:`vmware_host_vmhba_info <vmware_host_vmhba_info_module>` instead.
-
-* vmware_host_vmnic_facts use :ref:`vmware_host_vmnic_info <vmware_host_vmnic_info_module>` instead.
-
-* vmware_local_role_facts use :ref:`vmware_local_role_info <vmware_local_role_info_module>` instead.
-
-* vmware_local_user_facts use :ref:`vmware_local_user_info <vmware_local_user_info_module>` instead.
-
-* vmware_portgroup_facts use :ref:`vmware_portgroup_info <vmware_portgroup_info_module>` instead.
-
-* vmware_resource_pool_facts use :ref:`vmware_resource_pool_info <vmware_resource_pool_info_module>` instead.
-
-* vmware_target_canonical_facts use :ref:`vmware_target_canonical_info <vmware_target_canonical_info_module>` instead.
-
-* vmware_vmkernel_facts use :ref:`vmware_vmkernel_info <vmware_vmkernel_info_module>` instead.
-
-* vmware_vswitch_facts use :ref:`vmware_vswitch_info <vmware_vswitch_info_module>` instead.
-
-* vultr_account_facts use :ref:`vultr_account_info <vultr_account_info_module>` instead.
-
-* vultr_block_storage_facts use :ref:`vultr_block_storage_info <vultr_block_storage_info_module>` instead.
-
-* vultr_dns_domain_facts use :ref:`vultr_dns_domain_info <vultr_dns_domain_info_module>` instead.
-
-* vultr_firewall_group_facts use :ref:`vultr_firewall_group_info <vultr_firewall_group_info_module>` instead.
-
-* vultr_network_facts use :ref:`vultr_network_info <vultr_network_info_module>` instead.
-
-* vultr_os_facts use :ref:`vultr_os_info <vultr_os_info_module>` instead.
-
-* vultr_plan_facts use :ref:`vultr_plan_info <vultr_plan_info_module>` instead.
-
-* vultr_region_facts use :ref:`vultr_region_info <vultr_region_info_module>` instead.
-
-* vultr_server_facts use :ref:`vultr_server_info <vultr_server_info_module>` instead.
-
-* vultr_ssh_key_facts use :ref:`vultr_ssh_key_info <vultr_ssh_key_info_module>` instead.
-
-* vultr_startup_script_facts use :ref:`vultr_startup_script_info <vultr_startup_script_info_module>` instead.
-
-* vultr_user_facts use :ref:`vultr_user_info <vultr_user_info_module>` instead.
-
-* vyos_interface use :ref:`vyos_interfaces <vyos_interfaces_module>` instead.
-
-* vyos_l3_interface use :ref:`vyos_l3_interfaces <vyos_l3_interfaces_module>` instead.
-
-* vyos_linkagg use :ref:`vyos_lag_interfaces <vyos_lag_interfaces_module>` instead.
-
-* vyos_lldp use :ref:`vyos_lldp_global <vyos_lldp_global_module>` instead.
-
-* vyos_lldp_interface use :ref:`vyos_lldp_interfaces <vyos_lldp_interfaces_module>` instead.
-
-
-The following functionality will be removed in Ansible 2.12. Please update update your playbooks accordingly.
-
-* ``vmware_cluster`` DRS, HA and VSAN configuration; use :ref:`vmware_cluster_drs <vmware_cluster_drs_module>`, :ref:`vmware_cluster_ha <vmware_cluster_ha_module>` and :ref:`vmware_cluster_vsan <vmware_cluster_vsan_module>` instead.
-
-
-The following functionality will be removed in Ansible 2.13. Please update update your playbooks accordingly.
-
-* ``openssl_certificate`` deprecates the ``assertonly`` provider.
-  Please see the :ref:`openssl_certificate <openssl_certificate_module>` documentation examples on how to
-  replace the provider with the :ref:`openssl_certificate_info <openssl_certificate_info_module>`,
-  :ref:`openssl_csr_info <openssl_csr_info_module>`, :ref:`openssl_privatekey_info <openssl_privatekey_info_module>`
-  and :ref:`assert <assert_module>` modules.
-
-
-For the following modules, the PyOpenSSL-based backend ``pyopenssl`` has been deprecated and will be
-removed in Ansible 2.13:
-
-* :ref:`get_certificate <get_certificate_module>`
-* :ref:`openssl_certificate <openssl_certificate_module>`
-* :ref:`openssl_certificate_info <openssl_certificate_info_module>`
-* :ref:`openssl_csr <openssl_csr_module>`
-* :ref:`openssl_csr_info <openssl_csr_info_module>`
-* :ref:`openssl_privatekey <openssl_privatekey_module>`
-* :ref:`openssl_privatekey_info <openssl_privatekey_info_module>`
-* :ref:`openssl_publickey <openssl_publickey_module>`
-
-
-Renamed modules
-^^^^^^^^^^^^^^^
-
-The following modules have been renamed. The old name is deprecated and will
-be removed in Ansible 2.13. Please update update your playbooks accordingly.
-
-* The ``ali_instance_facts`` module was renamed to :ref:`ali_instance_info <ali_instance_info_module>`.
-* The ``aws_acm_facts`` module was renamed to :ref:`aws_acm_info <aws_acm_info_module>`.
-* The ``aws_az_facts`` module was renamed to :ref:`aws_az_info <aws_az_info_module>`.
-* The ``aws_caller_facts`` module was renamed to :ref:`aws_caller_info <aws_caller_info_module>`.
-* The ``aws_kms_facts`` module was renamed to :ref:`aws_kms_info <aws_kms_info_module>`.
-* The ``aws_region_facts`` module was renamed to :ref:`aws_region_info <aws_region_info_module>`.
-* The ``aws_s3_bucket_facts`` module was renamed to :ref:`aws_s3_bucket_info <aws_s3_bucket_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``aws_sgw_facts`` module was renamed to :ref:`aws_sgw_info <aws_sgw_info_module>`.
-* The ``aws_waf_facts`` module was renamed to :ref:`aws_waf_info <aws_waf_info_module>`.
-* The ``azure_rm_aks_facts`` module was renamed to :ref:`azure_rm_aks_info <azure_rm_aks_info_module>`.
-* The ``azure_rm_aksversion_facts`` module was renamed to :ref:`azure_rm_aksversion_info <azure_rm_aksversion_info_module>`.
-* The ``azure_rm_applicationsecuritygroup_facts`` module was renamed to :ref:`azure_rm_applicationsecuritygroup_info <azure_rm_applicationsecuritygroup_info_module>`.
-* The ``azure_rm_appserviceplan_facts`` module was renamed to :ref:`azure_rm_appserviceplan_info <azure_rm_appserviceplan_info_module>`.
-* The ``azure_rm_automationaccount_facts`` module was renamed to :ref:`azure_rm_automationaccount_info <azure_rm_automationaccount_info_module>`.
-* The ``azure_rm_autoscale_facts`` module was renamed to :ref:`azure_rm_autoscale_info <azure_rm_autoscale_info_module>`.
-* The ``azure_rm_availabilityset_facts`` module was renamed to :ref:`azure_rm_availabilityset <azure_rm_availabilityset_info_module>`.
-* The ``azure_rm_cdnendpoint_facts`` module was renamed to :ref:`azure_rm_cdnendpoint_info <azure_rm_cdnendpoint_info_module>`.
-* The ``azure_rm_cdnprofile_facts`` module was renamed to :ref:`azure_rm_cdnprofile_info <azure_rm_cdnprofile_info_module>`.
-* The ``azure_rm_containerinstance_facts`` module was renamed to :ref:`azure_rm_containerinstance_info <azure_rm_containerinstance_info_module>`.
-* The ``azure_rm_containerregistry_facts`` module was renamed to :ref:`azure_rm_containerregistry_info <azure_rm_containerregistry_info_module>`.
-* The ``azure_rm_cosmosdbaccount_facts`` module was renamed to :ref:`azure_rm_cosmosdbaccount_info <azure_rm_cosmosdbaccount_info_module>`.
-* The ``azure_rm_deployment_facts`` module was renamed to :ref:`azure_rm_deployment_info <azure_rm_deployment_info_module>`.
-* The ``azure_rm_resourcegroup_facts`` module was renamed to :ref:`azure_rm_resourcegroup_info <azure_rm_resourcegroup_info_module>`.
-* The ``bigip_device_facts`` module was renamed to :ref:`bigip_device_info <bigip_device_info_module>`.
-* The ``bigiq_device_facts`` module was renamed to :ref:`bigiq_device_info <bigiq_device_info_module>`.
-* The ``cloudformation_facts`` module was renamed to :ref:`cloudformation_info <cloudformation_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``cloudfront_facts`` module was renamed to :ref:`cloudfront_info <cloudfront_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``cloudwatchlogs_log_group_facts`` module was renamed to :ref:`cloudwatchlogs_log_group_info <cloudwatchlogs_log_group_info_module>`.
-* The ``digital_ocean_account_facts`` module was renamed to :ref:`digital_ocean_account_info <digital_ocean_account_info_module>`.
-* The ``digital_ocean_certificate_facts`` module was renamed to :ref:`digital_ocean_certificate_info <digital_ocean_certificate_info_module>`.
-* The ``digital_ocean_domain_facts`` module was renamed to :ref:`digital_ocean_domain_info <digital_ocean_domain_info_module>`.
-* The ``digital_ocean_firewall_facts`` module was renamed to :ref:`digital_ocean_firewall_info <digital_ocean_firewall_info_module>`.
-* The ``digital_ocean_floating_ip_facts`` module was renamed to :ref:`digital_ocean_floating_ip_info <digital_ocean_floating_ip_info_module>`.
-* The ``digital_ocean_image_facts`` module was renamed to :ref:`digital_ocean_image_info <digital_ocean_image_info_module>`.
-* The ``digital_ocean_load_balancer_facts`` module was renamed to :ref:`digital_ocean_load_balancer_info <digital_ocean_load_balancer_info_module>`.
-* The ``digital_ocean_region_facts`` module was renamed to :ref:`digital_ocean_region_info <digital_ocean_region_info_module>`.
-* The ``digital_ocean_size_facts`` module was renamed to :ref:`digital_ocean_size_info <digital_ocean_size_info_module>`.
-* The ``digital_ocean_snapshot_facts`` module was renamed to :ref:`digital_ocean_snapshot_info <digital_ocean_snapshot_info_module>`.
-* The ``digital_ocean_tag_facts`` module was renamed to :ref:`digital_ocean_tag_info <digital_ocean_tag_info_module>`.
-* The ``digital_ocean_volume_facts`` module was renamed to :ref:`digital_ocean_volume_info <digital_ocean_volume_info_module>`.
-* The ``ec2_ami_facts`` module was renamed to :ref:`ec2_ami_info <ec2_ami_info_module>`.
-* The ``ec2_asg_facts`` module was renamed to :ref:`ec2_asg_info <ec2_asg_info_module>`.
-* The ``ec2_customer_gateway_facts`` module was renamed to :ref:`ec2_customer_gateway_info <ec2_customer_gateway_info_module>`.
-* The ``ec2_eip_facts`` module was renamed to :ref:`ec2_eip_info <ec2_eip_info_module>`.
-* The ``ec2_elb_facts`` module was renamed to :ref:`ec2_elb_info <ec2_elb_info_module>`.
-* The ``ec2_eni_facts`` module was renamed to :ref:`ec2_eni_info <ec2_eni_info_module>`.
-* The ``ec2_group_facts`` module was renamed to :ref:`ec2_group_info <ec2_group_info_module>`.
-* The ``ec2_instance_facts`` module was renamed to :ref:`ec2_instance_info <ec2_instance_info_module>`.
-* The ``ec2_lc_facts`` module was renamed to :ref:`ec2_lc_info <ec2_lc_info_module>`.
-* The ``ec2_placement_group_facts`` module was renamed to :ref:`ec2_placement_group_info <ec2_placement_group_info_module>`.
-* The ``ec2_snapshot_facts`` module was renamed to :ref:`ec2_snapshot_info <ec2_snapshot_info_module>`.
-* The ``ec2_vol_facts`` module was renamed to :ref:`ec2_vol_info <ec2_vol_info_module>`.
-* The ``ec2_vpc_dhcp_option_facts`` module was renamed to :ref:`ec2_vpc_dhcp_option_info <ec2_vpc_dhcp_option_info_module>`.
-* The ``ec2_vpc_endpoint_facts`` module was renamed to :ref:`ec2_vpc_endpoint_info <ec2_vpc_endpoint_info_module>`.
-* The ``ec2_vpc_igw_facts`` module was renamed to :ref:`ec2_vpc_igw_info <ec2_vpc_igw_info_module>`.
-* The ``ec2_vpc_nacl_facts`` module was renamed to :ref:`ec2_vpc_nacl_info <ec2_vpc_nacl_info_module>`.
-* The ``ec2_vpc_nat_gateway_facts`` module was renamed to :ref:`ec2_vpc_nat_gateway_info <ec2_vpc_nat_gateway_info_module>`.
-* The ``ec2_vpc_net_facts`` module was renamed to :ref:`ec2_vpc_net_info <ec2_vpc_net_info_module>`.
-* The ``ec2_vpc_peering_facts`` module was renamed to :ref:`ec2_vpc_peering_info <ec2_vpc_peering_info_module>`.
-* The ``ec2_vpc_route_table_facts`` module was renamed to :ref:`ec2_vpc_route_table_info <ec2_vpc_route_table_info_module>`.
-* The ``ec2_vpc_subnet_facts`` module was renamed to :ref:`ec2_vpc_subnet_info <ec2_vpc_subnet_info_module>`.
-* The ``ec2_vpc_vgw_facts`` module was renamed to :ref:`ec2_vpc_vgw_info <ec2_vpc_vgw_info_module>`.
-* The ``ec2_vpc_vpn_facts`` module was renamed to :ref:`ec2_vpc_vpn_info <ec2_vpc_vpn_info_module>`.
-* The ``ecs_service_facts`` module was renamed to :ref:`ecs_service_info <ecs_service_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ecs_taskdefinition_facts`` module was renamed to :ref:`ecs_taskdefinition_info <ecs_taskdefinition_info_module>`.
-* The ``efs_facts`` module was renamed to :ref:`efs_info <efs_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``elasticache_facts`` module was renamed to :ref:`elasticache_info <elasticache_info_module>`.
-* The ``elb_application_lb_facts`` module was renamed to :ref:`elb_application_lb_info <elb_application_lb_info_module>`.
-* The ``elb_classic_lb_facts`` module was renamed to :ref:`elb_classic_lb_info <elb_classic_lb_info_module>`.
-* The ``elb_target_facts`` module was renamed to :ref:`elb_target_info <elb_target_info_module>`.
-* The ``elb_target_group_facts`` module was renamed to :ref:`elb_target_group_info <elb_target_group_info_module>`.
-* The ``gcp_bigquery_dataset_facts`` module was renamed to :ref:`gcp_bigquery_dataset_info <gcp_bigquery_dataset_info_module>`.
-* The ``gcp_bigquery_table_facts`` module was renamed to :ref:`gcp_bigquery_table_info <gcp_bigquery_table_info_module>`.
-* The ``gcp_cloudbuild_trigger_facts`` module was renamed to :ref:`gcp_cloudbuild_trigger_info <gcp_cloudbuild_trigger_info_module>`.
-* The ``gcp_compute_address_facts`` module was renamed to :ref:`gcp_compute_address_info <gcp_compute_address_info_module>`.
-* The ``gcp_compute_backend_bucket_facts`` module was renamed to :ref:`gcp_compute_backend_bucket_info <gcp_compute_backend_bucket_info_module>`.
-* The ``gcp_compute_backend_service_facts`` module was renamed to :ref:`gcp_compute_backend_service_info <gcp_compute_backend_service_info_module>`.
-* The ``gcp_compute_disk_facts`` module was renamed to :ref:`gcp_compute_disk_info <gcp_compute_disk_info_module>`.
-* The ``gcp_compute_firewall_facts`` module was renamed to :ref:`gcp_compute_firewall_info <gcp_compute_firewall_info_module>`.
-* The ``gcp_compute_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_forwarding_rule_info <gcp_compute_forwarding_rule_info_module>`.
-* The ``gcp_compute_global_address_facts`` module was renamed to :ref:`gcp_compute_global_address_info <gcp_compute_global_address_info_module>`.
-* The ``gcp_compute_global_forwarding_rule_facts`` module was renamed to :ref:`gcp_compute_global_forwarding_rule_info <gcp_compute_global_forwarding_rule_info_module>`.
-* The ``gcp_compute_health_check_facts`` module was renamed to :ref:`gcp_compute_health_check_info <gcp_compute_health_check_info_module>`.
-* The ``gcp_compute_http_health_check_facts`` module was renamed to :ref:`gcp_compute_http_health_check_info <gcp_compute_http_health_check_info_module>`.
-* The ``gcp_compute_https_health_check_facts`` module was renamed to :ref:`gcp_compute_https_health_check_info <gcp_compute_https_health_check_info_module>`.
-* The ``gcp_compute_image_facts`` module was renamed to :ref:`gcp_compute_image_info <gcp_compute_image_info_module>`.
-* The ``gcp_compute_instance_facts`` module was renamed to :ref:`gcp_compute_instance_info <gcp_compute_instance_info_module>`.
-* The ``gcp_compute_instance_group_facts`` module was renamed to :ref:`gcp_compute_instance_group_info <gcp_compute_instance_group_info_module>`.
-* The ``gcp_compute_instance_group_manager_facts`` module was renamed to :ref:`gcp_compute_instance_group_manager_info <gcp_compute_instance_group_manager_info_module>`.
-* The ``gcp_compute_instance_template_facts`` module was renamed to :ref:`gcp_compute_instance_template_info <gcp_compute_instance_template_info_module>`.
-* The ``gcp_compute_interconnect_attachment_facts`` module was renamed to :ref:`gcp_compute_interconnect_attachment_info <gcp_compute_interconnect_attachment_info_module>`.
-* The ``gcp_compute_network_facts`` module was renamed to :ref:`gcp_compute_network_info <gcp_compute_network_info_module>`.
-* The ``gcp_compute_region_disk_facts`` module was renamed to :ref:`gcp_compute_region_disk_info <gcp_compute_region_disk_info_module>`.
-* The ``gcp_compute_route_facts`` module was renamed to :ref:`gcp_compute_route_info <gcp_compute_route_info_module>`.
-* The ``gcp_compute_router_facts`` module was renamed to :ref:`gcp_compute_router_info <gcp_compute_router_info_module>`.
-* The ``gcp_compute_ssl_certificate_facts`` module was renamed to :ref:`gcp_compute_ssl_certificate_info <gcp_compute_ssl_certificate_info_module>`.
-* The ``gcp_compute_ssl_policy_facts`` module was renamed to :ref:`gcp_compute_ssl_policy_info <gcp_compute_ssl_policy_info_module>`.
-* The ``gcp_compute_subnetwork_facts`` module was renamed to :ref:`gcp_compute_subnetwork_info <gcp_compute_subnetwork_info_module>`.
-* The ``gcp_compute_target_http_proxy_facts`` module was renamed to :ref:`gcp_compute_target_http_proxy_info <gcp_compute_target_http_proxy_info_module>`.
-* The ``gcp_compute_target_https_proxy_facts`` module was renamed to :ref:`gcp_compute_target_https_proxy_info <gcp_compute_target_https_proxy_info_module>`.
-* The ``gcp_compute_target_pool_facts`` module was renamed to :ref:`gcp_compute_target_pool_info <gcp_compute_target_pool_info_module>`.
-* The ``gcp_compute_target_ssl_proxy_facts`` module was renamed to :ref:`gcp_compute_target_ssl_proxy_info <gcp_compute_target_ssl_proxy_info_module>`.
-* The ``gcp_compute_target_tcp_proxy_facts`` module was renamed to :ref:`gcp_compute_target_tcp_proxy_info <gcp_compute_target_tcp_proxy_info_module>`.
-* The ``gcp_compute_target_vpn_gateway_facts`` module was renamed to :ref:`gcp_compute_target_vpn_gateway_info <gcp_compute_target_vpn_gateway_info_module>`.
-* The ``gcp_compute_url_map_facts`` module was renamed to :ref:`gcp_compute_url_map_info <gcp_compute_url_map_info_module>`.
-* The ``gcp_compute_vpn_tunnel_facts`` module was renamed to :ref:`gcp_compute_vpn_tunnel_info <gcp_compute_vpn_tunnel_info_module>`.
-* The ``gcp_container_cluster_facts`` module was renamed to :ref:`gcp_container_cluster_info <gcp_container_cluster_info_module>`.
-* The ``gcp_container_node_pool_facts`` module was renamed to :ref:`gcp_container_node_pool_info <gcp_container_node_pool_info_module>`.
-* The ``gcp_dns_managed_zone_facts`` module was renamed to :ref:`gcp_dns_managed_zone_info <gcp_dns_managed_zone_info_module>`.
-* The ``gcp_dns_resource_record_set_facts`` module was renamed to :ref:`gcp_dns_resource_record_set_info <gcp_dns_resource_record_set_info_module>`.
-* The ``gcp_iam_role_facts`` module was renamed to :ref:`gcp_iam_role_info <gcp_iam_role_info_module>`.
-* The ``gcp_iam_service_account_facts`` module was renamed to :ref:`gcp_iam_service_account_info <gcp_iam_service_account_info_module>`.
-* The ``gcp_pubsub_subscription_facts`` module was renamed to :ref:`gcp_pubsub_subscription_info <gcp_pubsub_subscription_info_module>`.
-* The ``gcp_pubsub_topic_facts`` module was renamed to :ref:`gcp_pubsub_topic_info <gcp_pubsub_topic_info_module>`.
-* The ``gcp_redis_instance_facts`` module was renamed to :ref:`gcp_redis_instance_info <gcp_redis_instance_info_module>`.
-* The ``gcp_resourcemanager_project_facts`` module was renamed to :ref:`gcp_resourcemanager_project_info <gcp_resourcemanager_project_info_module>`.
-* The ``gcp_sourcerepo_repository_facts`` module was renamed to :ref:`gcp_sourcerepo_repository_info <gcp_sourcerepo_repository_info_module>`.
-* The ``gcp_spanner_database_facts`` module was renamed to :ref:`gcp_spanner_database_info <gcp_spanner_database_info_module>`.
-* The ``gcp_spanner_instance_facts`` module was renamed to :ref:`gcp_spanner_instance_info <gcp_spanner_instance_info_module>`.
-* The ``gcp_sql_database_facts`` module was renamed to :ref:`gcp_sql_database_info <gcp_sql_database_info_module>`.
-* The ``gcp_sql_instance_facts`` module was renamed to :ref:`gcp_sql_instance_info <gcp_sql_instance_info_module>`.
-* The ``gcp_sql_user_facts`` module was renamed to :ref:`gcp_sql_user_info <gcp_sql_user_info_module>`.
-* The ``gcp_tpu_node_facts`` module was renamed to :ref:`gcp_tpu_node_info <gcp_tpu_node_info_module>`.
-* The ``gcpubsub_facts`` module was renamed to :ref:`gcpubsub_info <gcpubsub_info_module>`.
-* The ``github_webhook_facts`` module was renamed to :ref:`github_webhook_info <github_webhook_info_module>`.
-* The ``gluster_heal_facts`` module was renamed to :ref:`gluster_heal_info <gluster_heal_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hcloud_datacenter_facts`` module was renamed to :ref:`hcloud_datacenter_info <hcloud_datacenter_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hcloud_floating_ip_facts`` module was renamed to :ref:`hcloud_floating_ip_info <hcloud_floating_ip_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hcloud_image_facts`` module was renamed to :ref:`hcloud_image_info <hcloud_image_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hcloud_location_facts`` module was renamed to :ref:`hcloud_location_info <hcloud_location_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hcloud_server_facts`` module was renamed to :ref:`hcloud_server_info <hcloud_server_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hcloud_server_type_facts`` module was renamed to :ref:`hcloud_server_type_info <hcloud_server_type_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hcloud_ssh_key_facts`` module was renamed to :ref:`hcloud_ssh_key_info <hcloud_ssh_key_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hcloud_volume_facts`` module was renamed to :ref:`hcloud_volume_info <hcloud_volume_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``hpilo_facts`` module was renamed to :ref:`hpilo_info <hpilo_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``iam_mfa_device_facts`` module was renamed to :ref:`iam_mfa_device_info <iam_mfa_device_info_module>`.
-* The ``iam_role_facts`` module was renamed to :ref:`iam_role_info <iam_role_info_module>`.
-* The ``iam_server_certificate_facts`` module was renamed to :ref:`iam_server_certificate_info <iam_server_certificate_info_module>`.
-* The ``idrac_redfish_facts`` module was renamed to :ref:`idrac_redfish_info <idrac_redfish_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``intersight_facts`` module was renamed to :ref:`intersight_info <intersight_info_module>`.
-* The ``jenkins_job_facts`` module was renamed to :ref:`jenkins_job_info <jenkins_job_info_module>`.
-* The ``k8s_facts`` module was renamed to :ref:`k8s_info <k8s_info_module>`.
-* The ``memset_memstore_facts`` module was renamed to :ref:`memset_memstore_info <memset_memstore_info_module>`.
-* The ``memset_server_facts`` module was renamed to :ref:`memset_server_info <memset_server_info_module>`.
-* The ``one_image_facts`` module was renamed to :ref:`one_image_info <one_image_info_module>`.
-* The ``onepassword_facts`` module was renamed to :ref:`onepassword_info <onepassword_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``oneview_datacenter_facts`` module was renamed to :ref:`oneview_datacenter_info <oneview_datacenter_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``oneview_enclosure_facts`` module was renamed to :ref:`oneview_enclosure_info <oneview_enclosure_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``oneview_ethernet_network_facts`` module was renamed to :ref:`oneview_ethernet_network_info <oneview_ethernet_network_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``oneview_fc_network_facts`` module was renamed to :ref:`oneview_fc_network_info <oneview_fc_network_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``oneview_fcoe_network_facts`` module was renamed to :ref:`oneview_fcoe_network_info <oneview_fcoe_network_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``oneview_logical_interconnect_group_facts`` module was renamed to :ref:`oneview_logical_interconnect_group_info <oneview_logical_interconnect_group_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``oneview_network_set_facts`` module was renamed to :ref:`oneview_network_set_info <oneview_network_set_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``oneview_san_manager_facts`` module was renamed to :ref:`oneview_san_manager_info <oneview_san_manager_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_flavor_facts`` module was renamed to :ref:`os_flavor_info <os_flavor_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_image_facts`` module was renamed to :ref:`os_image_info <os_image_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_keystone_domain_facts`` module was renamed to :ref:`os_keystone_domain_info <os_keystone_domain_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_networks_facts`` module was renamed to :ref:`os_networks_info <os_networks_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_port_facts`` module was renamed to :ref:`os_port_info <os_port_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_project_facts`` module was renamed to :ref:`os_project_info <os_project_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_server_facts`` module was renamed to :ref:`os_server_info <os_server_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_subnets_facts`` module was renamed to :ref:`os_subnets_info <os_subnets_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``os_user_facts`` module was renamed to :ref:`os_user_info <os_user_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_affinity_label_facts`` module was renamed to :ref:`ovirt_affinity_label_info <ovirt_affinity_label_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_api_facts`` module was renamed to :ref:`ovirt_api_info <ovirt_api_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_cluster_facts`` module was renamed to :ref:`ovirt_cluster_info <ovirt_cluster_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_datacenter_facts`` module was renamed to :ref:`ovirt_datacenter_info <ovirt_datacenter_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_disk_facts`` module was renamed to :ref:`ovirt_disk_info <ovirt_disk_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_event_facts`` module was renamed to :ref:`ovirt_event_info <ovirt_event_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_external_provider_facts`` module was renamed to :ref:`ovirt_external_provider_info <ovirt_external_provider_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_group_facts`` module was renamed to :ref:`ovirt_group_info <ovirt_group_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_host_facts`` module was renamed to :ref:`ovirt_host_info <ovirt_host_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_host_storage_facts`` module was renamed to :ref:`ovirt_host_storage_info <ovirt_host_storage_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_network_facts`` module was renamed to :ref:`ovirt_network_info <ovirt_network_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_nic_facts`` module was renamed to :ref:`ovirt_nic_info <ovirt_nic_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_permission_facts`` module was renamed to :ref:`ovirt_permission_info <ovirt_permission_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_quota_facts`` module was renamed to :ref:`ovirt_quota_info <ovirt_quota_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_scheduling_policy_facts`` module was renamed to :ref:`ovirt_scheduling_policy_info <ovirt_scheduling_policy_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_snapshot_facts`` module was renamed to :ref:`ovirt_snapshot_info <ovirt_snapshot_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_storage_domain_facts`` module was renamed to :ref:`ovirt_storage_domain_info <ovirt_storage_domain_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_storage_template_facts`` module was renamed to :ref:`ovirt_storage_template_info <ovirt_storage_template_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_storage_vm_facts`` module was renamed to :ref:`ovirt_storage_vm_info <ovirt_storage_vm_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_tag_facts`` module was renamed to :ref:`ovirt_tag_info <ovirt_tag_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_template_facts`` module was renamed to :ref:`ovirt_template_info <ovirt_template_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_user_facts`` module was renamed to :ref:`ovirt_user_info <ovirt_user_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_vm_facts`` module was renamed to :ref:`ovirt_vm_info <ovirt_vm_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``ovirt_vmpool_facts`` module was renamed to :ref:`ovirt_vmpool_info <ovirt_vmpool_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``python_requirements_facts`` module was renamed to :ref:`python_requirements_info <python_requirements_info_module>`.
-* The ``rds_instance_facts`` module was renamed to :ref:`rds_instance_info <rds_instance_info_module>`.
-* The ``rds_snapshot_facts`` module was renamed to :ref:`rds_snapshot_info <rds_snapshot_info_module>`.
-* The ``redfish_facts`` module was renamed to :ref:`redfish_info <redfish_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``redshift_facts`` module was renamed to :ref:`redshift_info <redshift_info_module>`.
-* The ``route53_facts`` module was renamed to :ref:`route53_info <route53_info_module>`.
-* The ``smartos_image_facts`` module was renamed to :ref:`smartos_image_info <ali_instance_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``vertica_facts`` module was renamed to :ref:`vertica_info <vertica_info_module>`.
-  When called with the new name, the module no longer returns ``ansible_facts``.
-  To access return values, :ref:`register a variable <registered_variables>`.
-* The ``vmware_cluster_facts`` module was renamed to :ref:`vmware_cluster_info <vmware_cluster_info_module>`.
-* The ``vmware_datastore_facts`` module was renamed to :ref:`vmware_datastore_info <vmware_datastore_info_module>`.
-* The ``vmware_guest_facts`` module was renamed to :ref:`vmware_guest_info <vmware_guest_info_module>`.
-* The ``vmware_guest_snapshot_facts`` module was renamed to :ref:`vmware_guest_snapshot_info <vmware_guest_snapshot_info_module>`.
-* The ``vmware_tag_facts`` module was renamed to :ref:`vmware_tag_info <vmware_tag_info_module>`.
-* The ``vmware_vm_facts`` module was renamed to :ref:`vmware_vm_info <vmware_vm_info_module>`.
-* The ``xenserver_guest_facts`` module was renamed to :ref:`xenserver_guest_info <xenserver_guest_info_module>`.
-* The ``zabbix_group_facts`` module was renamed to :ref:`zabbix_group_info <zabbix_group_info_module>`.
-* The ``zabbix_host_facts`` module was renamed to :ref:`zabbix_host_info <zabbix_host_info_module>`.
-
-Noteworthy module changes
--------------------------
-
-* **Security Issue** Setting ``bind_pw`` with the ``params`` option for the ``ldap_entry`` and
-  ``ldap_attr`` modules has been disallowed.  If ``bind_pw`` was set with ``params``, the value could
-  have ended up in a logfile or displayed on stdout.  Set ``bind_pw`` directly, with the modules'
-  options instead.
-* :ref:`vmware_cluster <vmware_cluster_module>` was refactored for easier maintenance/bugfixes. Use the three new, specialized modules to configure clusters. Configure DRS with :ref:`vmware_cluster_drs <vmware_cluster_drs_module>`, HA with :ref:`vmware_cluster_ha <vmware_cluster_ha_module>` and vSAN with :ref:`vmware_cluster_vsan <vmware_cluster_vsan_module>`.
-* :ref:`vmware_dvswitch <vmware_dvswitch_module>` accepts ``folder`` parameter to place dvswitch in user defined folder. This option makes ``datacenter`` as an optional parameter.
-* :ref:`vmware_datastore_cluster <vmware_datastore_cluster_module>` accepts ``folder`` parameter to place datastore cluster in user defined folder. This option makes ``datacenter`` as an optional parameter.
-* :ref:`mysql_db <mysql_db_module>` returns new ``db_list`` parameter in addition to ``db`` parameter. This ``db_list`` parameter refers to list of database names. ``db`` parameter will be deprecated in version 2.13.
-* :ref:`snow_record <snow_record_module>` and :ref:`snow_record_find <snow_record_find_module>` now takes environment variables for ``instance``, ``username`` and ``password`` parameters. This change marks these parameters as optional.
-* The deprecated ``force`` option in ``win_firewall_rule`` has been removed.
-* :ref:`openssl_certificate <openssl_certificate_module>`'s ``ownca`` provider creates authority key identifiers if not explicitly disabled with ``ownca_create_authority_key_identifier: no``. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available.
-* :ref:`openssl_certificate <openssl_certificate_module>`'s ``ownca`` and ``selfsigned`` providers create subject key identifiers if not explicitly disabled with ``ownca_create_subject_key_identifier: never_create`` resp. ``selfsigned_create_subject_key_identifier: never_create``. If a subject key identifier is provided by the CSR, it is taken; if not, it is created from the public key. This is only the case for the ``cryptography`` backend, which is selected by default if the ``cryptography`` library is available.
-* :ref:`openssh_keypair <openssh_keypair_module>` now applies the same file permissions and ownership to both public and private keys (both get the same ``mode``, ``owner``, ``group``, etc.). If you need to change permissions / ownership on one key, use the :ref:`file <file_module>` to modify it after it is created.
-* :ref:`acme_certificate <acme_certificate_module>` only returns challenges that need to be satisfied in ``challenge_data`` and ``challenge_data_dns`` (since Ansible 2.8.5). Depending on how you process challenges, you need to adjust your challenge satisfying tasks to either use ``when:`` to only process domain names which appear in ``challenge_data``, or by looping over the ``challenge_data`` dictionary itself. See the updated examples in the module documentation.
-
-
-Plugins
-=======
-
-Removed Lookup Plugins
-----------------------
-
-* ``redis_kv`` use :ref:`redis <redis_lookup>` instead.
-
-
-Porting custom scripts
-======================
-
-No notable changes
-
-
-Networking
-==========
-
-Network resource modules
-------------------------
-
-Ansible 2.9 introduced the first batch of network resource modules. Sections of a network device's configuration can be thought of as a resource provided by that device. Network resource modules are intentionally scoped to configure a single resource and you can combine them as building blocks to configure complex network services. The older modules are deprecated in Ansible 2.9 and will be removed in Ansible 2.13. You should scan the list of deprecated modules above and replace them with the new network resource modules in your playbooks. See `Ansible Network Features in 2.9 <https://www.ansible.com/blog/network-features-coming-soon-in-ansible-engine-2.9>`_ for details.
-
-Improved ``gather_facts`` support for network devices
------------------------------------------------------
-
-In Ansible 2.9, the ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device. You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`eos_facts <eos_facts_module>`) to return just a subset of the device configuration.  See :ref:`network_gather_facts` for an example.
-
-Top-level connection arguments removed in 2.9
----------------------------------------------
-
-Top-level connection arguments like ``username``, ``host``, and ``password`` are  removed in version 2.9.
-
-**OLD** In Ansible < 2.4
-
-.. code-block:: yaml
-
-    - name: example of using top-level options for connection properties
-      ios_command:
-        commands: show version
-        host: "{{ inventory_hostname }}"
-        username: cisco
-        password: cisco
-        authorize: yes
-        auth_pass: cisco
-
-
-Change your playbooks to the connection types ``network_cli`` and ``netconf`` using standard Ansible connection properties, and setting those properties in inventory by group. As you update your playbooks and inventory files, you can easily make the change to ``become`` for privilege escalation (on platforms that support it). For more information, see the :ref:`using become with network modules<become_network>` guide and the :ref:`platform documentation<platform_options>`.
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
diff --git a/docs/docsite/rst/porting_guides/porting_guides.rst b/docs/docsite/rst/porting_guides/porting_guides.rst
index 1f93b574c3..3dc29127ed 100644
--- a/docs/docsite/rst/porting_guides/porting_guides.rst
+++ b/docs/docsite/rst/porting_guides/porting_guides.rst
@@ -4,13 +4,8 @@
 Ansible Porting Guides
 **********************
 
-This section lists porting guides that can help you in updating playbooks, plugins and other parts of your Ansible infrastructure from one version of Ansible to the next.
+Ansible Porting Guides are maintained in the ``devel`` branch only. Please go to `the devel porting guides <https://docs.ansible.com/ansible/devel/porting_guides/porting_guides.html>`_ for up to date information.
 
-Please note that this is not a complete list. If you believe any extra information would be useful in these pages, you can edit by clicking `Edit on GitHub` on the top right, or raising an issue.
+.. note::
 
-.. toctree::
-   :maxdepth: 2
-   :glob:
-   :reversed:
-
-   porting_guide_*
+	This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.