It was also mentioned in the call chat, CPython uses cherry-picker[1] to automatically create cherry-pick PRs for version branches. They have a GitHub bot that listens to PR events, and when a PR is merged to main, automatically creates back-porting PRs. You can see it in action here[2] (just a random PR).
They use labels to determine what versions to back port to, but the case is a lot simpler for Airflow—I think we simply needs to apply one label to mark a PR should be back ported. If the tool encounters any problems during cherry-picking (generally conflicts), the bot would also comment in the original PR to ask for a back port to be manually created[3]. They have additional bots to ensure this is enforced, but again Airflow probably does not need this much infrastructure. [1]: https://pypi.org/project/cherry_picker/ [2]: https://github.com/python/cpython/pull/122312 [3]: https://github.com/python/cpython/pull/27625#issuecomment-894672175 > On 27 Jul 2024, at 01:07, Kaxil Naik <kaxiln...@gmail.com> wrote: > > 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 <mailto:t...@astronomer.io> ? > > If anyone has other ideas or thoughts, let's discuss them here. > > Regards, > Kaxil >
