Add start-beta-process command to cut beta pre-releases

Betas are cut from vX-Y-test only: there is no vX-Y-stable branch yet and
no sync PR (a sync PR exists only to carry changes from vX-Y-test into
vX-Y-stable for an rc or final), and there is no vote. start-rc-process
requires the stable branch and a sync branch, so a beta had to be cut by
hand. A dedicated command keeps start-rc-process untouched and models the
real beta flow: tag the vX-Y-test tip (the version-bump and release-notes
commits are pushed there beforehand through normal PRs) and tag the
constraints at the constraints-X-Y branch tip rather than running the
release-constraints workflow, which a beta's resolution does not need.

Author: vatsrahul1001

dev/README_RELEASE_AIRFLOW.md

@@ -114,6 +114,32 @@ moves `vX-Y-test` forward to the current `main` - only the branch-specific commi
 `Update default branches for X.Y`) are kept on top of `main`. Each beta is cut from the branch
 in that state, so everything merged to `main` lands in the next beta.
 
+### Cutting a beta
+
+A beta is cut with `breeze release-management start-beta-process`, not `start-rc-process`. A beta is
+released from `vX-Y-test` only: there is no `vX-Y-stable` branch yet and therefore no sync PR (a sync
+PR exists only to carry changes from `vX-Y-test` into `vX-Y-stable` for an `rc`/final), and there is
+no vote.
+
+1. Push the version-bump and release-notes commits to `vX-Y-test` through normal PRs, so the tip of
+   `vX-Y-test` is exactly what the beta should ship.
+2. Refresh the constraints: run the `Refresh constraints` workflow from `main` with `ref=vX-Y-test`,
+   which rewrites `constraints-X-Y` from that ref's sources. A beta pins providers at their released
+   versions (there is no provider wave on PyPI yet), so this tip is what the beta ships.
+3. Run:
+
+   ```shell script
+   breeze release-management start-beta-process \
+       --version ${VERSION} \
+       --previous-version ${PREVIOUS_VERSION} \
+       --task-sdk-version ${TASK_SDK_VERSION}
+   ```
+
+   It validates that `vX-Y-test` exists, checks out its tip, tags the beta there, builds and signs
+   the artifacts, tags `constraints-X.Y.0bN` at the `constraints-X-Y` tip (no `release-constraints`
+   workflow), uploads to SVN dev and PyPI, and pushes the tags. Everything downstream of the tag is
+   the same as an `rc`; only the branch/sync/constraints/vote handling differs.
+
 During this phase, all automation that would add commits directly to `vX-Y-test` must be paused -
 any such commit makes `vX-Y-test` diverge from `main` and breaks the next fast-forward. Upgrades and
 fixes land on `main` only and reach `vX-Y-test` with the next fast-forward. When you add the new

dev/breeze/doc/09_release_management_tasks.rst

@@ -176,6 +176,20 @@ automates it.
   :alt: Breeze release-management create-minor-branch
 
 
+Start beta process
+""""""""""""""""""
+
+When we prepare a beta pre-release, we automate some of the steps we need to do.
+
+.. code-block:: bash
+
+     breeze release-management start-beta-process
+
+.. image:: ./images/output_release-management_start-beta-process.svg
+  :target: https://raw.githubusercontent.com/apache/airflow/main/dev/breeze/doc/images/output_release-management_start-beta-process.svg
+  :width: 100%
+  :alt: Breeze release-management start-beta-process
+
 Start release candidate process
 """""""""""""""""""""""""""""""
 

dev/breeze/doc/images/output_release-management.svg

@@ -1 +1 @@
-016eb82c476bc36ac2bcb754d3e87919
+186f43f8d9e9e522daa2e16d537a46d3

dev/breeze/doc/images/output_release-management.txt

@@ -0,0 +1 @@
+571d4a7aa1b635323255d4bfe243d344

dev/breeze/doc/images/output_release-management_start-beta-process.svg

@@ -1 +1 @@
-071569892714c5561156e19cdaa04041
+cd743de2ac920faaec5a33b506ede093

dev/breeze/doc/images/output_release-management_start-beta-process.txt

@@ -1 +1 @@
-57d31722815e46eeb1cdf1b92d5a87b1
+b34bcd0ca3348d1279d48f96682a25e5