ci: add a helper script to bump the Release tags

.github/workflows/release.yml

@@ -9,11 +9,14 @@ name: release
 # lib/release.
 #
 # To update a release ref: open a PR that changes the Release row for that
-# kernel variant in ci/build-matrix.json. release-dry-run.yml builds the
-# changed rows on the PR, and merging it starts this workflow for exactly the
-# variants whose branch_or_tag changed, every suite of each. Nothing else in
-# the matrix starts a release. Every run still waits for approval in the
-# Production environment before building and again before promoting.
+# kernel variant in ci/build-matrix.json, or run
+# ci/scripts/propose-release-bump.py to open one that bumps every Release row
+# to its newest tag (it merges once checks pass and it is approved).
+# release-dry-run.yml builds the changed rows on the PR, and merging it starts
+# this workflow for exactly the variants whose branch_or_tag changed, every
+# suite of each. Nothing else in the matrix starts a release. Every run still
+# waits for approval in the Production environment before building and again
+# before promoting.
 #
 # Manual dispatch remains for releasing without a ref change and for retries.
 # There is intentionally no schedule trigger.

.gitignore

@@ -21,3 +21,6 @@ debian/linux-image-*.prerm
 # Default kernel source and build output directories
 kernel-source/
 kernel-build/
+
+# Script cache
+__pycache__/

README.md

@@ -163,6 +163,15 @@ Release is the controlled promotion path.
   counts as a change, so it releases the ref reverted to.
 - Before merge, `release-dry-run.yml` builds the same variants from the PR's
   new ref, chosen by the same script, and promotes nothing.
+- `ci/scripts/propose-release-bump.py` prepares that PR: it bumps every
+  Release row whose Daily row has a newer tag and commits that on a local
+  `bump/<timestamp>` branch, after showing the diff and asking. It then asks
+  again before pushing the branch and opening the PR with `gh`; `--no-push`
+  stops after the commit. Run it by hand, not from a workflow, so the PR
+  triggers `release-dry-run.yml`. The PR merges once the required checks
+  pass and it is approved, unless `--no-auto-merge`; `--dry-run` only shows
+  the diff. `--variant qcom-next[,...]` bumps only those variants, so the PR
+  does not overlap another open one.
 - A manual run uses one **Release scope** for a kernel variant:
   - **Selected variant (all suites)** promotes every configured Release suite
     for that variant.