I fully agree. We should document it. There is one exceptional case. In my view this should be planned and documented as exception: if something needs to be fixed that is not on main anymore (e.g. code to integrate Fab) then a fix pr mist be made against v2-10-test branch as it can not be made against main - also assuming that such big is not relevant for 3.x line.
Jens Sent from Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Kaxil Naik <kaxiln...@gmail.com> Sent: Friday, July 26, 2024 7:41 PM To: dev@airflow.apache.org <dev@airflow.apache.org> Subject: Re: [DISCUSS] Approaches to bugfixes for 2.10 after main becomes 3.0 Nice, that is indeed promising On Fri, 26 Jul 2024 at 18:30, Tzu-ping Chung <t...@astronomer.io.invalid> wrote: > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fcherry_picker%2F&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7C431ec61f820943c851e708dcad9a2968%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638576124826168130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xJ%2FAnqyHFyc6OHSr3t1ZAGmK%2FQjHJGLAm1nMa0nDXJI%3D&reserved=0<https://pypi.org/project/cherry_picker/> > [2]: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F122312&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7C431ec61f820943c851e708dcad9a2968%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638576124826178921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=4nKUiqqO0bc7BIiCTJ3UdjJA3bi5f7u%2B2Ry5d2BtRyo%3D&reserved=0<https://github.com/python/cpython/pull/122312> > [3]: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fpull%2F27625%23issuecomment-894672175&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7C431ec61f820943c851e708dcad9a2968%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638576124826185912%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Gf7Ey2quisKsdrlLRfkagjam0fTzM60WQP2cU8fPv4E%3D&reserved=0<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 > > > >
