Repository: ansible/ansible
Pull request: update backport instructions to reflect stable-2.13
##### SUMMARY
<!--- Describe the change below, including rationale and design decisions -->

<!--- HINT: Include "Fixes #nnn" if you are fixing an existing issue -->
Fixes #77574 77574
##### ISSUE TYPE
<!--- Pick one below and delete the rest -->
- Docs Pull Request

##### COMPONENT NAME
<!--- Write the short name of the module, plugin, task or feature below -->
docs/docsite/rst/community/development_process.rst

##### ADDITIONAL INFORMATION
<!--- Include additional information to help people understand the change here -->
<!--- A step-by-step reproduction of the problem is helpful if there is no related issue -->

<!--- Paste verbatim command output below, e.g. before and after your change -->
```paste below

```


Problem statement:
Documentation Checklist - ansible-core 2.13 release
### Summary

Documentation checklist to prepare for and deliver the ansible-core 2.13 release. See follow-on comment for the full checklist.

### Issue Type

Documentation Report

### Component Name

docs/docsite/sphinx_conf/core_conf.py

### Ansible Version

```console
$ ansible --version
2.13
```


### Configuration

```console
$ ansible-config dump --only-changed
```


### OS / Environment

n/a

### Additional Information

n/a

### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct

Hints from issue discussion:
Files identified in the description:
* [`docs/docsite/sphinx_conf/core_conf.py`](https://github.com/ansible/ansible/blob/devel/docs/docsite/sphinx_conf/core_conf.py)

If these files are incorrect, please update the `component name` section of the description or use the `!component` bot command.

[click here for bot help](https://github.com/ansible/ansibullbot/blob/devel/ISSUE_HELP.md)
<!--- boilerplate: components_banner --->
Tasks include:

~~- [ ] remove the release/maintenance page and porting guide pages from the new release when the branch is created and replace with stub page pointing up to the devel versions of these release-independent pages.~~  - no longer doing this. Will keep devel and latest in sync.
- [x] Review changelogs in stable-2.13 for ansible-core
- [x] Review ansible-core porting guide and ensure it links to core 2.13 changelogs
- [x] include ansible-core in Release Status Grid and ensure maintenance/eol releases listed accurately. Include links to changelogs.
- [x] Update core_conf.py:
    - [x] Set 'latest_version': '2.13 ', under html_context
    - [x] Update ‘available_versions’ to 2.13, 2.12, 2.11,  devel, under ‘html_context’.
    - [x] Merge to `devel`
    - [x] Backport to `stable-2.13`, `stable-2.12`, and `stable-2.11`
    - [x] Verify Ansible package porting guide and roadmaps are listed under ‘exclude_patterns’. 
    - [x] In `stable-2.13` - change VERSION (capitalized) from `devel` to `2.13`.

- [x] publish on release day.
- [ ] Translation docs for core:
    - [ ] test publish core-2.13 with japanese language selection in Jenkins job. If successful, publish to prod.
    - [ ] Update the docsite to include the new translation - see https://github.com/ansible/docsite/pull/77

Post release:
- [x] Update the backport instructions to target the new “latest” branch, see https://github.com/ansible/ansible/pull/56578 
- [x] Make sure all server-side redirects are updated as necessary - see https://github.com/ansible/docsite/pull/11 
- [x] Swiftype updates
  - [x] Update Swiftype Search engine for ansible-core to blacklist the EOL release (e.g. /ansible/2.9/  and ansible/2.10/) -
  - [x] Kick off a reindex on the swiftype engine
- [x] End-of-life the 2.9 docs
   - [x] In the EOL branch (stable-2.9), update page banner to EOL to the release no longer supported. Point to core docs for RH customers. See https://github.com/ansible/ansible/pull/76669/files
  - [x] In the EOL branch (stable-2.9), remove ansible_version.hml from layout.html in the theme.
 
- [x] End-of-life the 2.10 docs
   - [x] In the EOL branch (stable-2.10), update page banner to EOL to the release no longer supported. See https://github.com/ansible/ansible/pull/76669/files
  - [x] In the EOL branch (stable-2.10), remove ansible_version.hml from layout.html in the theme.

Commit message: update backport instructions to reflect stable-2.13

Patch to review:
diff --git a/docs/docsite/rst/community/development_process.rst b/docs/docsite/rst/community/development_process.rst
index 1e24a4cfda5904..35cb7cb4fe0ef9 100644
--- a/docs/docsite/rst/community/development_process.rst
+++ b/docs/docsite/rst/community/development_process.rst
@@ -360,7 +360,7 @@ We do **not** backport features.
 
    These instructions assume that:
 
-    * ``stable-2.12`` is the targeted release branch for the backport
+    * ``stable-2.13`` is the targeted release branch for the backport
     * ``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly.
     * ``https://github.com/<yourgithubaccount>/ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly.
 
@@ -369,7 +369,7 @@ We do **not** backport features.
 .. code-block:: shell
 
        git fetch upstream
-       git checkout -b backport/2.12/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.12
+       git checkout -b backport/2.12/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.13
 
 #. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:
 
@@ -383,15 +383,15 @@ We do **not** backport features.
 
 .. code-block:: shell
 
-       git push origin backport/2.12/[PR_NUMBER_FROM_DEVEL]
+       git push origin backport/2.13/[PR_NUMBER_FROM_DEVEL]
 
-#. Submit the pull request for ``backport/2.12/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.12`` branch
+#. Submit the pull request for ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.13`` branch
 
 #. The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green.
 
 .. note::
 
-    The branch name ``backport/2.12/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary, but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
+    The branch name ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary, but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
 
 .. note::
 


Code review comments:
diff_hunk: @@ -383,15 +383,15 @@ We do **not** backport features.
 
 .. code-block:: shell
 
-       git push origin backport/2.12/[PR_NUMBER_FROM_DEVEL]
+       git push origin backport/2.13/[PR_NUMBER_FROM_DEVEL]
 
-#. Submit the pull request for ``backport/2.12/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.12`` branch
+#. Submit the pull request for ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.13`` branch
 
 #. The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green.
 
 .. note::
 
-    The branch name ``backport/2.12/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary, but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
+    The branch name ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary, but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
path: docs/docsite/rst/community/development_process.rst
text: @user1:
```suggestion
    The branch name ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
```