Hi all, In the last Airflow 3 dev call yesterday, we agreed that the main branch will become the Airflow 3.0 branch on 9th August after 2.10.0rc1 is cut. Once that happens, we need to handle bugfixes PR differently, as we want to continue releasing bugfixes as part of 2.10 patch releases. The codebase in the main branch will contain breaking changes and might have diverged significantly from the 2.10 branch. This means the cherry-picking process isn't straightforward for PRs touching code is different for 2.10 vs 3.0.
There was a consensus that the general policy should be: "All bug fixes will target Airflow 3. We will make the best effort to make them available in 2.10.x, but if somebody wants to guarantee that a fix is included in 2.10.x, they need to raise the PR explicitly to the v2-10-test branch." My proposal is simple but manual: When merging bugfix PRs to the main branch, the committers should also try to cherry-pick it to v2-10-test branch. If there are merge conflicts, the committer should add a comment on the original PR, informing the author and asking them to raise a separate PR against v2-10-test branch. If this doesn't happen, there is no guarantee that the PR will be part of 2.10. TP mentioned that he knew of workflows used by some existing projects that we can compare and consider as an option. Could you expand on that, @Tzu-ping Chung <t...@astronomer.io> ? If anyone has other ideas or thoughts, let's discuss them here. Regards, Kaxil
