This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch v3-2-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/v3-2-test by this push:
new 4199e4e9a91 [v3-2-test] Doc: Add test-to-stable PR example with allow
provider dependency bump label (#65341) (#65352)
4199e4e9a91 is described below
commit 4199e4e9a91c10f4242c5dae9ec752c597ff67b7
Author: github-actions[bot]
<41898282+github-actions[bot]@users.noreply.github.com>
AuthorDate: Sun Apr 26 17:53:06 2026 +0200
[v3-2-test] Doc: Add test-to-stable PR example with allow provider
dependency bump label (#65341) (#65352)
* [v3-2-test] Bump actions/github-script in the github-actions-updates
group (#65150) (#65160)
Bumps the github-actions-updates group with 1 update:
[actions/github-script](https://github.com/actions/github-script).
Updates `actions/github-script` from 8.0.0 to 9.0.0
- [Release notes](https://github.com/actions/github-script/releases)
-
[Commits](https://github.com/actions/github-script/compare/ed597411d8f924073f98dfc5c65a23a2325f34cd...3a2844b7e9c422d3c10d287c895573f7108da1b3)
(cherry picked from commit e5a047ca8d23614cefeaad89e08eb1e3b0482e60)
---
updated-dependencies:
- dependency-name: actions/github-script
dependency-version: 9.0.0
dependency-type: direct:production
update-type: version-update:semver-major
dependency-group: github-actions-updates
...
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot]
<49699333+dependabot[bot]@users.noreply.github.com>
* [v3-2-test] Added breeze generate issue content for airflow-ctl (#65042)
(#65241)
* Add breeze generate issue content for airflow-ctl
* add new command to doc
(cherry picked from commit b24538b0bc3a53d8c666b62e52e023a17d102467)
Co-authored-by: Justin Pakzad
<[email protected]>
* [v3-2-test] Run release calendar verification on its own schedule
(#65118) (#65242)
* Move release calendar verification to its own scheduled workflow
Run dev/verify_release_calendar.py from a dedicated daily scheduled
workflow instead of as a canary job in the main CI pipeline, and
notify the #release-management Slack channel when the check fails so
the issue is surfaced to release managers directly.
* Include wiki and calendar links in release calendar Slack alert
(cherry picked from commit 048e9a191b4a6625bb4bbad23fad537b256f4062)
* [v3-2-test] Doc: Add test-to-stable PR example with allow provider
dependency bump label (#65341)
(cherry picked from commit bbec651e845c729053b9aac796dd6eaa12e100ac)
Co-authored-by: Jarek Potiuk <[email protected]>
---------
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: github-actions[bot]
<41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: dependabot[bot]
<49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Jarek Potiuk <[email protected]>
Co-authored-by: Justin Pakzad
<[email protected]>
---
dev/README_RELEASE_AIRFLOW.md | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/dev/README_RELEASE_AIRFLOW.md b/dev/README_RELEASE_AIRFLOW.md
index 80beae13d76..14142992e3f 100644
--- a/dev/README_RELEASE_AIRFLOW.md
+++ b/dev/README_RELEASE_AIRFLOW.md
@@ -503,6 +503,23 @@ uv tool install -e ./dev/breeze
- PR from the 'test' branch to the 'stable' branch
+ Cherry-picked commits often include provider dependency bumps (changes to
`>=` constraints on
+ `apache-airflow-providers-*` packages in `pyproject.toml`). CI blocks such
changes by default —
+ only Release Managers should perform them. To allow the PR to pass, add the
+ `allow provider dependency bump` label (and `skip common compat check` if
common.compat files
+ changed). For example:
+
+ ```shell script
+ gh pr create \
+ --base v3-2-stable \
+ --head v3-2-test \
+ --title "Airflow ${VERSION}: test to stable" \
+ --label "allow provider dependency bump" \
+ --label "skip common compat check" \
+ --body "Sync v3-2-test into v3-2-stable for Airflow ${VERSION} release." \
+ --web
+ ```
+
> [!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
