add docs for maintenance branches

.github/workflows/label-maker.yml

@@ -4,6 +4,8 @@ name: Label Maker
 
 on:
   push:
+    branches-ignore:
+      - release/v*
     paths:
       - .github/workflows/label-maker.yml
       - .github/labels.yml
@@ -12,7 +14,7 @@ on:
 jobs:
   label-maker:
     # Skip running the job from forks.
-    if: github.repository == 'rackspace/runway' && !endswith(github.actor, '[bot]')
+    if: github.repository == 'rackspace/runway' && !endswith(github.actor, '[bot]') && github.event
     runs-on: ubuntu-latest
     steps:
       - name: ⤵️ Check out code from GitHub

.github/workflows/spell-check.yml

@@ -8,6 +8,7 @@ on:
   push:
     branches:
       - master
+      - release/v*
 
 env:
   NODE_VERSION: '20'

docs/source/maintainers/maintenance_branches.rst

@@ -0,0 +1,60 @@
+===================
+Maintenance Branchs
+===================
+
+A maintenance branch is a branch created to publish patches for releases that are no longer being actively developed (e.g. past major releases).
+For Runway, the naming format of these branches is ``release/v<major>``.
+
+-------------------------------------------------------------------------------
+
+
+*****************************
+Creating A Maintenance Branch
+*****************************
+
+A new maintenance branch should be created prior to beginning work on a new major release.
+It is best to create the branch prior to the final planned release (minor or patch) of the outgoing major version.
+This enables `release-drafter <https://github.com/release-drafter/release-drafter>`__ to create drafts for future releases.
+
+.. important::
+  When releasing the final release of the outgoing major version, create the tag on the maintenance branch.
+
+#. Clone the repo locally.
+#. Ensure that the default branch (e.g. ``master``) is up to date.
+#. Create the new maintenance branch locally.
+#. Push the maintenance branch to GitHub.
+
+
+Enable Documentation For A Maintenance Branch
+=============================================
+
+To be completed after the creation of a new maintenance branch.
+
+#. Navigate to the `ReadTheDocs project page <https://app.readthedocs.org/projects/runway/>`__
+#. Click **Add version**.
+#. Input the name of the maintenance branch, activate it, and click **Update version**.
+
+
+-------------------------------------------------------------------------------
+
+
+*****************************
+Patching A Maintenance Branch
+*****************************
+
+#. Clone the repo locally.
+#. Checkout the maintenance branch and ensure it is up to date.
+#. Create a new branch for the patch, make the required changes, commit the changes, and push to GitHub.
+#. Open a new PR ensuring the **change the base branch** to the desired maintenance branch.
+#. Merge the PR once all requirements are met.
+#. Refer to the :ref:`maintainers/release_process:Maintenance Branch` release process.
+
+
+-------------------------------------------------------------------------------
+
+
+******************************
+Maintenance Branch End Of Life
+******************************
+
+TBD

docs/source/maintainers/release_process.rst

@@ -6,24 +6,24 @@ Release Process
 
 Steps that should be taken when preparing for and executing a release.
 
+**************
+Default Branch
+**************
 
+Releases from the branch being actively developed (e.g. ``master``).
 
-***********
 Preparation
-***********
+===========
 
 #. Merge all PRs that should be included in the release.
 #. Ensure that all checks have completed and passed on the *master* branch.
 
-
-*********
 Execution
-*********
+=========
 
 #. Navigate to the Releases_ section of the repository on GitHub.
    There should be a *Draft* already started that was automatically generated from PRs that were merged since the last release.
 #. Enter the *Edit* screen of the *Draft*.
-
 #. The *Title* and *Tag* fields should already be filled in with the correct values (e.g. ``v<major>.<minor>.<patch>``).
    Ensure these values match what is expected.
    The *Tag* should also be targeting the *master* branch.
@@ -34,3 +34,31 @@ Execution
 
 At this point, GitHub Actions will begin building the deployment package & automatically publishing it to PyPI.
 The **Publish Release** workflow can be monitored for progress.
+
+
+-------------------------------------------------------------------------------
+
+
+******************
+Maintenance Branch
+******************
+
+Release from a branch created to patch previous major releases (e.g. ``release/v2``) until they reach end of life.
+
+Prepararing A Maintenance Release
+=================================
+
+#. Merge all PRs based on and targeting the maintenance branch that should be included in the release.
+#. Ensure that all checks have completed and passed on the maintenance branch.
+
+Executing A Maintenance Release
+===============================
+
+#. Navigate to the Releases_ section of the repository on GitHub.
+   There should be a *Draft* already started that was automatically generated from PRs that were merged since the last release from the maintenance branch.
+#. Enter the *Edit* screen of the *Draft*.
+#. The *Title* and *Tag* fields should already be filled in with the correct values (e.g. ``v<major>.<minor>.<patch>``).
+   Ensure these values match what is expected.
+   The *Tag* should also be targeting the *master* branch.
+#. Edit the description of the release as needed but, there should be little to no changes required if all PRs were properly labeled.
+#. Publish the release.