Airflow-ctl release docs: branch from core vX-Y-stable, not vX-Y-test by potiuk · Pull Request #65606 · apache/airflow

potiuk · 2026-04-21T15:09:49Z

Core Airflow `vX-Y-test` may carry cherry-picks destined for the next patch (e.g. 3.2.2) that have not yet been released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to `vX-Y-stable` instead so the cut matches the most recently released core Airflow X.Y.Z.

Caught while preparing airflow-ctl 0.1.4rc3 — `v3-2-test` currently contains a get_task_instances cursor-pagination commit destined for 3.2.2 that should not be in the 0.1.4 cut.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines

core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:12:34Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

bugraoz93

This makes sense! Additionally, as you mentioned, it is the most trusted branch where we can release the airflowctl.
Would we then sync the changes from airflow-ctl/..test branch to the stable branch while releasing? At least that's what I assume

bugraoz93 · 2026-04-21T18:16:32Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

Totally agree on this Jarek!

github-actions · 2026-04-21T18:19:51Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 9a5485d v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

…est (apache#65606) core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:09:49Z

Core Airflow `vX-Y-test` may carry cherry-picks destined for the next patch (e.g. 3.2.2) that have not yet been released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to `vX-Y-stable` instead so the cut matches the most recently released core Airflow X.Y.Z.

Caught while preparing airflow-ctl 0.1.4rc3 — `v3-2-test` currently contains a get_task_instances cursor-pagination commit destined for 3.2.2 that should not be in the 0.1.4 cut.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines

core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:12:34Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

bugraoz93

This makes sense! Additionally, as you mentioned, it is the most trusted branch where we can release the airflowctl.
Would we then sync the changes from airflow-ctl/..test branch to the stable branch while releasing? At least that's what I assume

bugraoz93 · 2026-04-21T18:16:32Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

Totally agree on this Jarek!

github-actions · 2026-04-21T18:19:51Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 9a5485d v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

…est (apache#65606) core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:09:49Z

Core Airflow `vX-Y-test` may carry cherry-picks destined for the next patch (e.g. 3.2.2) that have not yet been released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to `vX-Y-stable` instead so the cut matches the most recently released core Airflow X.Y.Z.

Caught while preparing airflow-ctl 0.1.4rc3 — `v3-2-test` currently contains a get_task_instances cursor-pagination commit destined for 3.2.2 that should not be in the 0.1.4 cut.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines

core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:12:34Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

bugraoz93

This makes sense! Additionally, as you mentioned, it is the most trusted branch where we can release the airflowctl.
Would we then sync the changes from airflow-ctl/..test branch to the stable branch while releasing? At least that's what I assume

bugraoz93 · 2026-04-21T18:16:32Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

Totally agree on this Jarek!

github-actions · 2026-04-21T18:19:51Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 9a5485d v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

…est (apache#65606) core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:09:49Z

Core Airflow `vX-Y-test` may carry cherry-picks destined for the next patch (e.g. 3.2.2) that have not yet been released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to `vX-Y-stable` instead so the cut matches the most recently released core Airflow X.Y.Z.

Caught while preparing airflow-ctl 0.1.4rc3 — `v3-2-test` currently contains a get_task_instances cursor-pagination commit destined for 3.2.2 that should not be in the 0.1.4 cut.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines

core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:12:34Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

bugraoz93

This makes sense! Additionally, as you mentioned, it is the most trusted branch where we can release the airflowctl.
Would we then sync the changes from airflow-ctl/..test branch to the stable branch while releasing? At least that's what I assume

bugraoz93 · 2026-04-21T18:16:32Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

Totally agree on this Jarek!

github-actions · 2026-04-21T18:19:51Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 9a5485d v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

…est (apache#65606) core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:09:49Z

Core Airflow `vX-Y-test` may carry cherry-picks destined for the next patch (e.g. 3.2.2) that have not yet been released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to `vX-Y-stable` instead so the cut matches the most recently released core Airflow X.Y.Z.

Caught while preparing airflow-ctl 0.1.4rc3 — `v3-2-test` currently contains a get_task_instances cursor-pagination commit destined for 3.2.2 that should not be in the 0.1.4 cut.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines

core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:12:34Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

bugraoz93

This makes sense! Additionally, as you mentioned, it is the most trusted branch where we can release the airflowctl.
Would we then sync the changes from airflow-ctl/..test branch to the stable branch while releasing? At least that's what I assume

bugraoz93 · 2026-04-21T18:16:32Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

Totally agree on this Jarek!

github-actions · 2026-04-21T18:19:51Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 9a5485d v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

…est (apache#65606) core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:09:49Z

Core Airflow `vX-Y-test` may carry cherry-picks destined for the next patch (e.g. 3.2.2) that have not yet been released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to `vX-Y-stable` instead so the cut matches the most recently released core Airflow X.Y.Z.

Caught while preparing airflow-ctl 0.1.4rc3 — `v3-2-test` currently contains a get_task_instances cursor-pagination commit destined for 3.2.2 that should not be in the 0.1.4 cut.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines

core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:12:34Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

bugraoz93

This makes sense! Additionally, as you mentioned, it is the most trusted branch where we can release the airflowctl.
Would we then sync the changes from airflow-ctl/..test branch to the stable branch while releasing? At least that's what I assume

bugraoz93 · 2026-04-21T18:16:32Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

Totally agree on this Jarek!

github-actions · 2026-04-21T18:19:51Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 9a5485d v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

…est (apache#65606) core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:09:49Z

Core Airflow `vX-Y-test` may carry cherry-picks destined for the next patch (e.g. 3.2.2) that have not yet been released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to `vX-Y-stable` instead so the cut matches the most recently released core Airflow X.Y.Z.

Caught while preparing airflow-ctl 0.1.4rc3 — `v3-2-test` currently contains a get_task_instances cursor-pagination commit destined for 3.2.2 that should not be in the 0.1.4 cut.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines

core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:12:34Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

bugraoz93

This makes sense! Additionally, as you mentioned, it is the most trusted branch where we can release the airflowctl.
Would we then sync the changes from airflow-ctl/..test branch to the stable branch while releasing? At least that's what I assume

bugraoz93 · 2026-04-21T18:16:32Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

Totally agree on this Jarek!

github-actions · 2026-04-21T18:19:51Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 9a5485d v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

…est (apache#65606) core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:09:49Z

Core Airflow `vX-Y-test` may carry cherry-picks destined for the next patch (e.g. 3.2.2) that have not yet been released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to `vX-Y-stable` instead so the cut matches the most recently released core Airflow X.Y.Z.

Caught while preparing airflow-ctl 0.1.4rc3 — `v3-2-test` currently contains a get_task_instances cursor-pagination commit destined for 3.2.2 that should not be in the 0.1.4 cut.

Was generative AI tooling used to co-author this PR?

Yes — Claude Opus 4.7 (1M context)

Generated-by: Claude Opus 4.7 (1M context) following the guidelines

core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk · 2026-04-21T15:12:34Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

bugraoz93

This makes sense! Additionally, as you mentioned, it is the most trusted branch where we can release the airflowctl.
Would we then sync the changes from airflow-ctl/..test branch to the stable branch while releasing? At least that's what I assume

bugraoz93 · 2026-04-21T18:16:32Z

cc: @bugraoz93 -> I found out that it's better to branch off from stable - because it then reflects the current "to be released" airflow in-progress or one that is alredy released. I think this is the best balance of "stability" and "novelty"

Totally agree on this Jarek!

github-actions · 2026-04-21T18:19:51Z

Backport failed to create: v3-2-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-2-test

You can attempt to backport this manually by running:

cherry_picker 9a5485d v3-2-test

This should apply the commit to the v3-2-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

…est (apache#65606) core Airflow vX-Y-test can carry commits destined for the next patch (e.g. 3.2.2) that are not yet released and are not compatible with the airflow-ctl version being cut. Anchor the airflow-ctl release-branch pair to vX-Y-stable instead so the cut matches the most recently released core Airflow X.Y.Z.

potiuk requested review from bugraoz93, jedcunningham, jscheffl, shahar1 and vincbeck as code owners April 21, 2026 15:09

boring-cyborgBot added area:dev-tools backport-to-v3-2-test labels Apr 21, 2026

potiuk mentioned this pull request Apr 21, 2026
Status of testing of Apache Airflow CTL 0.1.4rc2 #65497
Closed
29 tasks

bugraoz93 approved these changes Apr 21, 2026
View reviewed changes

potiuk merged commit 9a5485d into apache:mainApr 21, 2026
63 checks passed

potiuk deleted the fix-airflow-ctl-release-docs-branch-base branch April 21, 2026 18:18

This was referenced Apr 21, 2026
Prepare airflow-ctl 0.1.4rc3 release #65634
Merged
Status of testing of Apache Airflow CTL 0.1.4rc3 #65643
Closed