docs: tell how to do and request patch releases/backports (#3185)

We've had several backport requests of late. It's tenable for users to
do the more
time consuming working of backporting the code, so give steps on how to
do so.

Author: rickeylev

.github/ISSUE_TEMPLATE/patch_release_request.md

@@ -0,0 +1,22 @@
+---
+name: "🏗️ Patch release or backport"
+about: Request a patch release or backport of a fix to a release.
+title: 'Patch release: MAJOR.MINOR.PATCH'
+labels: 'type: process'
+---
+
+<!--
+Thank you for requesting a backport. Before submitting, please read:
+
+* Backport policy: https://rules-python.readthedocs.io/en/latest/support.html#backports-and-patch-releases
+-->
+
+**What version of `rules_python` do you want to patch?**
+
+
+**What pull requests do you want to backport?**
+
+Please provide a list of pull request numbers.
+
+- #
+- #

docs/devguide.md

@@ -116,3 +116,35 @@ to have everything self-documented, we have a special target,
 `//private:requirements.update`, which uses `rules_multirun` to run all
 of the requirement-updating scripts in sequence in one go. This can be done once per release as
 we prepare for releases.
+
+## Creating Backport PRs
+
+The steps to create a backport PR are:
+
+1.  Create an issue for the patch release; use the [patch relase
+    template][patch-release-issue].
+2.  Create a fork of `rules_python`.
+3.  Checkout the `release/X.Y` branch.
+4.  Use `git cherry-pick -x` to cherry pick the desired fixes.
+5.  Update the release's `CHANGELOG.md` file:
+    * Add a Major.Minor.Patch section if one doesn't exist
+    * Copy the changelog text from `main` to the release's changelog.
+6.  Send a PR with the backport's changes.
+    * The title should be `backport: PR#N to Major.Minor`
+    * The body must preserve the original PR's number, commit hash, description,
+      and authorship.
+      Use the following format (`git cherry-pick` will use this format):
+      ```
+      <original PR title>
+
+      <original PR body>
+      (cherry picked from commit <commit hash>)
+      -----
+      Co-authored-by: <original PR author; separate lines for each>
+      ```
+    * If the PR contains multiple backport commits, separate each's description
+      with `-----`.
+7.  Send a PR to update the `main` branch's `CHANGELOG.md` to reflect the
+    changes done in the patched release.
+
+[patch-release-issue]: https://github.com/bazelbuild/rules_python/issues/new?template=patch_release.md

docs/support.md

@@ -14,6 +14,22 @@ the willingness of volunteers.
 If you want or need particular functionality backported, then the best way
 is to open a PR to demonstrate the feasibility of the backport.
 
+### Backports and Patch Releases
+
+Backports and patch releases are provided on a best-effort basis. Only fixes are
+backported. Features are not backported.
+
+Backports can be done to older releases, but only if newer releases also have
+the fix backported. For example, if the current release is 1.5, in order to
+patch 1.4, version 1.5 must be patched first.
+
+Backports can be requested by [creating an issue with the patch release
+template][patch-release-issue] or by sending a pull request performing the backport.
+See the dev guide for [how to create a backport PR][backport-pr].
+
+[patch-release-issue]: https://github.com/bazelbuild/rules_python/issues/new?template=patch_release_request.md
+[backport-pr]: devguide.html#creating-backport-prs
+
 ## Supported Bazel Versions
 
 The supported Bazel versions are: