[2.3][backport] Update eol docs for 2.3 (#72760)

* manually stub out old porting guides

(cherry picked from commit dedd8fa771c7ffa9f06f154075aca810864b4f76)

* manually remove Edit on Github

(cherry picked from commit d5c30abccaffa2a09778a2c9d58301f4a0b2453b)

* add eol banner

(cherry picked from commit 5daf37d89e0b7321d78b0e53f55d3978af93b3db)

* point all older release pages to devel (#71428)

(cherry picked from commit 3be597419d5656ea69fa7c505f196d528af07914)
(cherry picked from commit 35abfbf5823d4439c9f2e68d616bff1fbcb43e74)

7 files changed, 32 insertions, 757 deletions

diff --git a/docs/docsite/_themes/srtd/ansible_eol_banner.html b/docs/docsite/_themes/srtd/ansible_eol_banner.html
new file mode 100644
index 0000000000..6f19d2c2e1
--- /dev/null
+++ b/docs/docsite/_themes/srtd/ansible_eol_banner.html
@@ -0,0 +1,4 @@
+{# Creates a banner at the top of the page for EOL versions. #}
+<div id='banner' class='Admonition caution'>
+  <p>You are reading an unmaintained version of the Ansible documentation. Unmaintained Ansible versions can contain unfixed security vulnerabilities (CVE). Please upgrade to a maintained version. See <a href="https://docs.ansible.com/ansible/latest/index.html">the latest Ansible documentation</a>.</p>
+</div>
diff --git a/docs/docsite/_themes/srtd/breadcrumbs.html b/docs/docsite/_themes/srtd/breadcrumbs.html
index c052c0bde1..6d403561cc 100644
--- a/docs/docsite/_themes/srtd/breadcrumbs.html
+++ b/docs/docsite/_themes/srtd/breadcrumbs.html
@@ -1,11 +1,5 @@
 <ul class="wy-breadcrumbs">
   <li><a href="{{ pathto(master_doc) }}">Docs</a> &raquo;</li>
   <li><a href="">{{ title }}</a></li>
-  {% if not pagename.endswith('_module') and (not 'list_of' in pagename) and (not 'category' in pagename) %}
-    <li class="wy-breadcrumbs-aside">
-      <a href="https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/{{ pagename }}.rst" class="icon icon-github"> Edit on GitHub</a>
-    </li>
-  {% endif %}
 </ul>
 <hr/>
-
diff --git a/docs/docsite/_themes/srtd/layout.html b/docs/docsite/_themes/srtd/layout.html
index 14ad17aa95..95f3f671ac 100644
--- a/docs/docsite/_themes/srtd/layout.html
+++ b/docs/docsite/_themes/srtd/layout.html
@@ -158,16 +158,16 @@
         <a class="DocSiteProduct-header DocSiteProduct-header--core" href="http://docs.ansible.com">
             <div class="DocSiteProduct-productName">
                 <div class="DocSiteProduct-logoText">
-                    Ansible Core   
+                    Ansible Core
                     <div class="DocSiteProduct-CurrentVersion" align="right">
                       v2.3
                   </div>
                 </div>
             </div>
         </a>
-        
 
-          <div class="DocSiteProduct-CheckVersionPara">For previous versions, see the  <a class="DocSiteProduct-versionheader" href="http://docs.ansible.com/">documentation archive.</a></div> 
+
+          <div class="DocSiteProduct-CheckVersionPara">For previous versions, see the  <a class="DocSiteProduct-versionheader" href="http://docs.ansible.com/">documentation archive.</a></div>
       </div>
 
       <div id="menu-id" class="wy-menu wy-menu-vertical" data-spy="affix">
@@ -228,6 +228,7 @@
         </div> -->
 
           {% include "breadcrumbs.html" %}
+          {% include "ansible_eol_banner.html" %}
           <div id="page-content">
           {% block body %}{% endblock %}
           </div>
diff --git a/docs/docsite/rst/porting_guide_2.0.rst b/docs/docsite/rst/porting_guide_2.0.rst
index fc38cadb4b..00879a6bb0 100644
--- a/docs/docsite/rst/porting_guide_2.0.rst
+++ b/docs/docsite/rst/porting_guide_2.0.rst
@@ -1,398 +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 <https://github.com/ansible/ansible/blob/devel/CHANGELOG.md#2.0>`_ 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 `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: foo.yml
-        a: 1
-
-Should now be::
-
-    - include: 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: foo.yml tags=a,b,c
-
-  Should be::
-
-    - include: 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.::
-
-    with_items: "{{vars['myvar_' + res_of_name]}}"
-
-  Or `hostvars[inventory_hostname]['myvar_' + rest_of_name]` if appropriate.
-
-* 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 __main__ 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: :doc:`dev_guide/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_guide_2.3.rst b/docs/docsite/rst/porting_guide_2.3.rst
index 8b096e0ca6..a003ba3f69 100644
--- a/docs/docsite/rst/porting_guide_2.3.rst
+++ b/docs/docsite/rst/porting_guide_2.3.rst
@@ -1,246 +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 <https://github.com/ansible/ansible/blob/devel/CHANGELOG.md#2.3>`_ 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:: yaml
-
-    - 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:: yaml
-
-    "ansible_distribution": "OpenBSD"
-    "ansible_distribution_release": "6.0",
-    "ansible_distribution_version": "release",
-
-**NEW** In Ansible 2.3:
-
-
-.. code-block:: yaml
-
-    "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:: yaml
-
-    - 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.
-
-* :ref:`ec2_vpc <ec2_vpc>`
-* :ref:`cl_bond <cl_bond>`
-* :ref:`cl_bridge <cl_bridge>`
-* :ref:`cl_img_install <cl_img_install>`
-* :ref:`cl_interface <cl_interface>`
-* :ref:`cl_interface_policy <cl_interface_policy>`
-* :ref:`cl_license <cl_license>`
-* :ref:`cl_ports <cl_ports>`
-* :ref:`nxos_mtu <nxos_mtu>` use :ref:`nxos_system <nxos_system>` instead
-
-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:: 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
-
-Will result in:
-
-.. code-block:: yaml
-
-   [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:: yaml
-
-   - 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 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, 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.
-
-.. code-block:: ini
-
-    [nxos]
-    nxos01
-    nxos02
-
-    [nxos:vars]
-    ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"'
-
-
-With the configuration above, simply build and run the playbook as normal with
-no additional changes necessary.  The network module will now connect to the
-network device by first connecting to the host specified in
-``ansible_ssh_common_args`` which is ``bastion01`` in the above example.
-
-
-.. notes: Using ``ProxyCommand`` with passwords via variables
-
-   It is a feature that SSH doesn't support providing passwords via environment variables.
-   This is done to prevent secrets from leaking out, for example in ``ps`` output.
+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.
 
-   We recommend using SSH Keys, and if needed and ssh-agent, rather than passwords, where ever possible.
+.. 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.rst b/docs/docsite/rst/porting_guides.rst
index 4c1dbec5fd..3dc29127ed 100644
--- a/docs/docsite/rst/porting_guides.rst
+++ b/docs/docsite/rst/porting_guides.rst
@@ -4,9 +4,8 @@
 Ansible Porting Guides
 **********************
 
-This section lists porting guides that can help you playbooks, plugins and other parts of your Ansible infrastructure from one version of Ansible to the next. 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.
+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.
 
+.. note::
 
-* :ref:`Ansible 1.x to 2.0 porting guide <porting_2.0_guide>`
-* :ref:`Ansible 2.2 to 2.3 porting guide <porting_2.3_guide>`
-* :ref:`Ansible 2.3 to 2.4 porting guide <porting_2.4_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.
diff --git a/docs/docsite/rst/release_and_maintenance.rst b/docs/docsite/rst/release_and_maintenance.rst
index 8898b1ceff..5a467a627f 100644
--- a/docs/docsite/rst/release_and_maintenance.rst
+++ b/docs/docsite/rst/release_and_maintenance.rst
@@ -1,123 +1,20 @@
 Release and maintenance
 =======================
 
-.. contents:: Topics
-   :local:
-
-.. _schedule:
-
-Release cycle
-`````````````
-
-Ansible is developed and released on a flexible 4 months release cycle.
-This cycle can be extended in order to allow for larger changes to be properly
-implemented and tested before a new release is made available.
-
-Ansible supports the two most recent major stable releases.
-For more information, read about the
-`development and stable version maintenance workflow`_.
-
-If you are using a release of Ansible that is no longer supported, we strongly
-encourage you to upgrade as soon as possible in order to benefit from the
-latest features and security fixes.
-
-Older unsupported versions of Ansible can contain unfixed security
-vulnerabilities (*CVE*).
-
-You can refer to the `porting guide`_ for tips on updating your Ansible
-playbooks to run on newer versions.
-
-.. _porting guide: https://docs.ansible.com/ansible/porting_guide_2.0.html
-
-Release status
-``````````````
-
-+-----------------+----------------------------+----------------------------------------+
-| Ansible release | Latest version             | Status                                 |
-+=================+============================+========================================+
-| devel           | `2.4`_ (unreleased, trunk) | In development                         |
-+-----------------+----------------------------+----------------------------------------+
-| 2.3             | `2.3.1`_ (2017-06-01)      | Supported (bug **and** security fixes) |
-+-----------------+----------------------------+----------------------------------------+
-| 2.2             | `2.2.3`_ (2017-05-09)      | Supported (**only** security fixes)    |
-+-----------------+----------------------------+----------------------------------------+
-| 2.1             | `2.1.6`_ (2017-06-01)      | Unsupported (end of life)              |
-+-----------------+----------------------------+----------------------------------------+
-| 2.0             | `2.0.2`_ (2016-04-19)      | Unsupported (end of life)              |
-+-----------------+----------------------------+----------------------------------------+
-| 1.9             | `1.9.6`_ (2016-04-15)      | Unsupported (end of life)              |
-+-----------------+----------------------------+----------------------------------------+
-| <1.9            | n/a                        | Unsupported (end of life)              |
-+-----------------+----------------------------+----------------------------------------+
-
-.. _2.4: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
-.. _2.3.1: https://github.com/ansible/ansible/blob/stable-2.3/CHANGELOG.md
-.. _2.2.3: https://github.com/ansible/ansible/blob/stable-2.2/CHANGELOG.md
-.. _2.1.6: https://github.com/ansible/ansible/blob/stable-2.1/CHANGELOG.md
-.. _2.0.2: https://github.com/ansible/ansible/blob/stable-2.0/CHANGELOG.md
-.. _1.9.6: https://github.com/ansible/ansible/blob/stable-1.9/CHANGELOG.md
-
+.. _release_cycle:
+.. _release_schedule:
 .. _support_life:
 .. _methods:
+.. _development_and_stable_version_maintenance_workflow:
+.. _release_changelogs:
+.. _release_freezing:
 
-Development and stable version maintenance workflow
-```````````````````````````````````````````````````
-
-The Ansible community develops and maintains Ansible on GitHub_.
-
-New modules, plugins, features and bugfixes will always be integrated in what
-will become the next major version of Ansible.
-This work is tracked on the ``devel`` git branch.
-
-Ansible provides bugfixes and security improvements for the most recent major
-release while the previous major release will only receive security patches.
-This work is tracked on the ``stable-<version>`` git branches.
-
-The fixes that land in supported stable branches will eventually be released
-as a new version when necessary.
-
-For more information on the changes included in each new version, you can refer
-to the changelog_, available on GitHub.
-
-Note that while there are no guarantees for providing fixes for unsupported
-releases of Ansible, there can sometimes be exceptions for critical issues.
-
-.. _GitHub: https://github.com/ansible/ansible
-.. _changelog: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
-
-Release candidates
-~~~~~~~~~~~~~~~~~~
-
-Before a new release or version of Ansible can be done, it will typically go
-through a release candidate process.
-
-This provides the Ansible community the opportunity to test Ansible and report
-bugs or issues they might come across.
-
-Ansible tags the first release candidate (``RC1``) which is usually scheduled
-to last five business days. The final release is done if no major bugs or
-issues are identified during this period.
-
-If there are major problems with the first candidate, a second candidate will
-be tagged (``RC2``) once the necessary fixes have landed.
-This second candidate lasts for a shorter duration than the first.
-If no problems have been reported after two business days, the final release is
-done.
-
-More release candidates can be tagged as required, so long as there are
-bugs that the Ansible core maintainers consider should be fixed before the
-final release.
-
-.. _freezing:
+Please go to `the devel release and maintenance page <https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html>`_ for up to date information.
 
-Feature freeze
-~~~~~~~~~~~~~~
+.. note::
 
-While there is a pending release candidate, the focus of core developers and
-maintainers will on fixes towards the release candidate.
+	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.
 
-Merging new features or fixes that are not related to the release candidate may
-be delayed in order to allow the new release to be shipped as soon as possible.
 
 .. seealso::
 
@@ -127,11 +24,9 @@ be delayed in order to allow the new release to be shipped as soon as possible.
        Testing strategies
    :doc:`community`
        Community information and contributing
-   `Ansible Changelog <https://github.com/ansible/ansible/blob/devel/CHANGELOG.md>`_
-       Documentation of the improvements for each version of Ansible
-   `Ansible release tarballs <https://releases.ansible.com/ansible/>`_
+  `Ansible release tarballs <https://releases.ansible.com/ansible/>`_
        Ansible release tarballs
-   `Development Mailing List <http://groups.google.com/group/ansible-devel>`_
+  `Development Mailing List <https://groups.google.com/group/ansible-devel>`_
        Mailing list for development topics
-   `irc.freenode.net <http://irc.freenode.net>`_
+  `irc.freenode.net <http://irc.freenode.net>`_
        #ansible IRC chat channel