Update backport instructions to apply to any release

- Remove interaction with DP0.2
- Use more obvious alias for release number

Author: yalsayyad

work/backports.rst

@@ -2,81 +2,73 @@
 Backporting Tickets to a Release Branch
 #######################################
 
-So you have a ticket that you think should be backported to ``v23.0.0`` and/or be used for DP0.2.
-What next?
+So you have a ticket that you think should be backported to the release branch? What next?
+Note, these instructions use v88 as an alias for the release of the science pipelines to backport to.
+Replace the 88 with 24, 27, or whatever major release number we are on now.
 
-1) First, add the label "backport-v23" to your jira ticket.
+1) First, add the label "backport-v88" to your jira ticket.
 
-   This will flag it for review by the DM-CCB or the DP0.2 campaign managers.
+   This will flag it for review by the DM-CCB.
    Continue merging your ticket to the default branch (``main``) and mark the ticket ``Done`` per instructions in the normal :doc:`flow`.
 
-2) Wait for approval. The ticket will gain the label "backport-approved."  A comment will be posted on the ticket that you may start the backporting process.
+2) Wait for approval. The ticket will gain the label "backport-approved."
 
-3) Checkout the release branch, ``v23.0.x``, for each repo affected by your ticket.
+3) Checkout the release branch, ``v88.0.x``, for each repo affected by your ticket.
 
    .. code-block:: bash
 
-      git checkout v23.0.x
+      git checkout v88.0.x
 
-   If the repo does not already have a ``v23.0.x`` branch, you need to create one based on ``v23.0.0.rc1`` (not the latest rcN, although that should be identical):
+   If the repo does not already have a ``v88.0.x`` branch, you need to create one based on ``v88.0.0.rc1`` (not the latest rcN, although that should be identical):
 
    .. code-block:: bash
 
-      git checkout v23.0.0.rc1
-      git checkout -b v23.0.x
-      git push -u origin v23.0.x
+      git checkout v88.0.0.rc1
+      git checkout -b v88.0.x
+      git push -u origin v88.0.x
 
-   Now treat ``v23.0.x`` same as you would the default branch (``main``).
+   Now treat ``v88.0.x`` same as you would the default branch (``main``).
 
-4) Create a copy of your ticket branch called ``tickets/DM-XXXXX-v23``.
+4) Create a copy of your ticket branch called ``tickets/DM-XXXXX-v88``.
 
    .. code-block:: bash
 
       git checkout tickets/DM-XXXXX
-      git checkout -b tickets/DM-XXXXX-v23
-      git rebase --onto v23.0.x <sha_of_last_commit_before_your_branch>
+      git checkout -b tickets/DM-XXXXX-v88
+      git rebase --onto v88.0.x <sha_of_last_commit_before_your_branch>
 
    In a new clone, this branch may not exist anymore if you have already merged your PR because merged branches may be automatically deleted.
-   In this case, you can branch ``tickets/DM-XXXXX-v23`` from ``v23.0.x``, and cherry-pick the ticket commits.
+   In this case, you can branch ``tickets/DM-XXXXX-v88`` from ``v88.0.x``, and cherry-pick the ticket commits.
 
    .. code-block:: bash
 
-      git checkout v23.0.x
-      git checkout -b tickets/DM-XXXXX-v23
+      git checkout v88.0.x
+      git checkout -b tickets/DM-XXXXX-v88
       git cherry-pick <ticket commit>
 
    The following may help you find your hash[es] from ``main``:
    ``git show --quiet $(git log --oneline | grep 'Merge.*DM-XXXXX' | cut -d' ' -f1)^2``
 
 5) Resolve any rebase or cherry-pick problems depending on your method.
    Continue using the same procedure outlined in :ref:`review-preparation`.
-   Check that it cleanly builds via scons. There should be a latest shared v23.0.0.rcN stack on lsst-devl.
+   Check that it cleanly builds via scons. There should be a latest shared v88.0.0.rcN stack on lsst-devl.
    Run Jenkins. When running Jenkins, build against the release branch and rc1 even if later rcNs exist.
-   The default ``SPLENV_REF`` may no longer be appropriate for ``v23.0.x``.
+   The default ``SPLENV_REF`` may no longer be appropriate for ``v88.0.x``.
    If you are unsure of the recommended env for the release, check with the release manager.
 
    .. code-block:: bash
 
-      REFS: tickets/DM-XXXXX-v23 v23.0.x v23.0.0.rc1
+      REFS: tickets/DM-XXXXX-v88 v88.0.x v88.0.0.rc1
       PRODUCTS: lsst_distrib lsst_ci ci_imsim ci_hsc
-      SPLENV_REF: 0.8.0
+      SPLENV_REF: <default_or_recommended_for_release>
 
    You may find that the ticket cannot be cleanly backported without first backporting another ticket.
 
-6) When it passes, merge to ``v23.0.x`` using the same procedure outlined in :ref:`workflow-code-review-merge`,
+6) When it passes, merge to ``v88.0.x`` using the same procedure outlined in :ref:`workflow-code-review-merge`,
    including creating a pull request.
-   On your pull request, remember to change the base branch to ``v23.0.x``.
+   On your pull request, remember to change the base branch to ``v88.0.x``.
    If the backport was clean, you may self-review.
    If the backport was not clean and you would like another pair of eyes, you may ask someone to hit the "Approved" button on GitHub,
    but please *do not* put your ticket status back into ``In Review`` on Jira.
 
-7) When merged to ``v23.0.x``, label your Jira ticket ``backport-done``.
-
-
-Interaction between v23 and DP0.2
----------------------------------
-Before the full-scale data release processing of step1 commences for DP0.2, a new rcN release will be built on approximately weekly cadence.
-This weekly cadence follows the weekly review of backport requests.
-
-After step1 begins and 23.0.0 is released, the current plan is to increment the release versions.
-This backporting process will remain the same, but with evolving release tags and release branch numbers.
+7) When merged to ``v88.0.x``, label your Jira ticket ``backport-done``.