This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new f4713de23ce Docs: Add RC shortcut for first release candidates from
test branch (#64528)
f4713de23ce is described below
commit f4713de23ce9f2d7d794bab384179566d7d54b81
Author: Jarek Potiuk <[email protected]>
AuthorDate: Tue Mar 31 12:59:20 2026 +0200
Docs: Add RC shortcut for first release candidates from test branch (#64528)
* Docs: Add RC shortcut for first release candidates from test branch
* Add RC shortcut docs to release instructions and fix pip install command
---
dev/README_AIRFLOW3_DEV.md | 11 +++++++++++
dev/README_RELEASE_AIRFLOW.md | 15 +++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/dev/README_AIRFLOW3_DEV.md b/dev/README_AIRFLOW3_DEV.md
index 75001d298cb..dbd7e919984 100644
--- a/dev/README_AIRFLOW3_DEV.md
+++ b/dev/README_AIRFLOW3_DEV.md
@@ -72,6 +72,17 @@ If you want to have a fix backported to 3.2.x please add (or
request to add) "ba
When preparing a new 3.2.x release, the release manager will sync the
`v3-2-test` branch to `v3-2-stable` and cut the release from the stable branch.
PRs should **never** target `v3-2-stable` directly unless explicitly
instructed by the release manager.
+> [!TIP]
+> **Shortcut for first RC candidates:** When preparing the first RC candidate
for a new minor release
+> (e.g., 3.2.0rc1), it is unlikely to be approved on the first attempt — bugs
are typically found during
+> RC testing. In this case, the release manager can prepare the RC directly
from the `v3-X-test` branch
+> without opening a PR to `v3-X-stable`. This saves the overhead of creating
and managing a PR that will
+> likely need additional changes before GA. However, when using this shortcut,
the release manager **must**
+> verify that the `v3-X-test` push CI action ("Tests" workflow) has succeeded
before cutting the RC. You can
+> check this at:
+>
https://github.com/apache/airflow/actions/workflows/ci-amd-arm.yml?query=event%3Apush+branch%3Av3-2-test
+> (adjust the branch filter for the relevant `v3-X-test` branch).
+
## Developing for Airflow 3
PRs should target `main` branch.
diff --git a/dev/README_RELEASE_AIRFLOW.md b/dev/README_RELEASE_AIRFLOW.md
index bdd91d63eab..cfc78e826c9 100644
--- a/dev/README_RELEASE_AIRFLOW.md
+++ b/dev/README_RELEASE_AIRFLOW.md
@@ -501,10 +501,21 @@ uv tool install -e ./dev/breeze
- PR from the 'test' branch to the 'stable' branch
-- When the PR is approved, install `dev/breeze` in a virtualenv:
+> [!TIP]
+> **Shortcut for first RC candidates:** When preparing the first RC candidate
for a new minor release
+> (e.g., 3.2.0rc1), it is unlikely to be approved on the first attempt — bugs
are typically found during
+> RC testing. In this case, the release manager can prepare the RC directly
from the `v3-X-test` branch
+> without opening a PR to `v3-X-stable`. This saves the overhead of creating
and managing a PR that will
+> likely need additional changes before GA. However, when using this shortcut,
the release manager **must**
+> verify that the `v3-X-test` push CI action ("Tests" workflow) has succeeded
before cutting the RC. You can
+> check this at:
+>
https://github.com/apache/airflow/actions/workflows/ci-amd-arm.yml?query=event%3Apush+branch%3Av3-2-test
+> (adjust the branch filter for the relevant `v3-X-test` branch).
+
+- When the PR is approved (or when using the shortcut above), install
`dev/breeze` in a virtualenv:
```shell script
- pip install -e ./dev/breeze
+ uv pip install -e ./dev/breeze
```
- Set `GITHUB_TOKEN` environment variable. Needed in patch release for
generating issue for testing of the RC.
