This is also what we did during Airflow 2 release and worked well for us where some changes were in Airflow 1 branch only since it had Flask Admin vs FAB, and their were no concept of Provider in v1, Python 2 support etc
On Sun, 28 Jul 2024 at 13:45, Kaxil Naik <kaxiln...@gmail.com> wrote: > @Jens: yup precisely, I do expect changes to only v2 branch. This is also > what we did during v2 release and worked well for us. > > On Sun, 28 Jul 2024 at 11:59, Ephraim Anierobi <ephraimanier...@gmail.com> > wrote: > >> From how the cherrypicker works, it looks like something we need. We could >> have a bot that adds a "review comment" that must be resolved before >> merging. The review comment can ask for a label to be added to the PR if >> the PR should be backported to Airflow 2. Whoever is merging the PR can >> determine if it should be backported or not and add the appropriate label. >> >> >> On Fri, 26 Jul 2024 at 20:14, Jarek Potiuk <ja...@potiuk.com> wrote: >> >> > Same comment as Jens. There will be things removed in Airflow-3 that >> will >> > need only-Airflow-2 fixes. >> > >> > I like the idea of automated cherry-picker, but it only make sense if we >> > pay attention to which PRs are going to be cherry-picked and do so at >> the >> > moment of merging - we are going to have many changes that will not be >> > supposed to be cherry-picked, so we need to have "opt-in" approach >> where we >> > explicitly say "this PR should be cherry-picked to v2". >> > >> > I think it's absolutely worth doing it- cherry-picking in sequential >> order >> > as things are merged makes a lot of sense - but it needs some >> deliberation >> > and decision making at the moment of merging (should this one be >> > cherry-picked?) - and assigning responsibility to who should be making >> that >> > decision. But 100% I think it makes sense to do it at "merge" time >> rather >> > than release time, because rather than having to make 100 decisions by a >> > single person at release time, 100 people might make separate decisions >> > (and follow-up when cherry-pick fails) for a long time. >> > >> > So technically it's fine, but it needs a well defined process and (say) >> > everyone who is merging PRs to pay attention to it. It's more of a >> social >> > than technical problem. Not sure if we will be able to make it work with >> > our distributed setup. >> > >> > My 3 cents. >> > >> > J. >> > >> > >> > On Fri, Jul 26, 2024 at 8:45 PM Scheffler Jens (XC-AS/EAE-ADA-T) >> > <jens.scheff...@de.bosch.com.invalid> wrote: >> > >> > > 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 >> > > > > >> > > > >> > > > >> > > >> > >> >
