Just one comment - following our discussion.. I perfectly understand we want to take more control now on what is merged. And if you want to take responsibility there then I am fine ( but also do not envy you :)
I think we just need to clarify who and when should add the backport-to labels PRS (if at all). Just to understand it. Because I understood it a bit differently this morning. I understand that you would prefer no one to set the backport label at all and you will identify what to cherry pick and do it ? I am talking about changes to 'airflow sources'. Do I understand correctly? I guess we allow some exceptions. I think (from past experience) would like to treat the CI / breeze related changes a bit differently - things tend to decay there pretty quickly - we still have some chicken/egg providers there and we have likely some doc things to fix etc.etc.and it is far easier to cherry-pick all those changes rather than subset of those. I will for sure want to keep on backporting (with label) all necessary CI /breeze /dependency changes from main to keep builds green. Happy to wait for your merges there, but I thi k also iterating on those backporting PR to make the latest v3-0-test green will make your life easier and I am happy to help with that. Not sure if there are other exceptions that are similar ? Does all I wrote make sense :) ? J. pt., 11 kwi 2025, 14:05 użytkownik Kaxil Naik <kaxiln...@gmail.com> napisał: > Hey everyone, > > As we approach the final stages of the Airflow 3.0.0 release, the main > branch is now officially targeting Airflow 3.1. > > *What this means*: > • PR authors and contributors should continue working as usual -- nothing > changes in how PRs are submitted or merged. > • However, starting now, all new changes merged into main will be > considered part of 3.1. > • If a change should be included in 3.0.0, I’ll cherry-pick it into the > v3-0-test branch or rebase to main in case there are no 3.1 changes and all > changes merged-to-main are bugfixes and crucial for 3.0.0 - and I’ll reach > out to authors directly if anything needs clarification. > > *Why now?* > > We are at a stage where stability matters more than velocity. I expect RC2 > to help surface any remaining issues, and I’d like RC3 to be our final RC. > Having a tighter grip on post-RC2 changes gives us a better shot at getting > there without another RC cycle. > > I’ll actively sync main and v3-0-test multiple times a day and compare > diffs between them to ensure no important changes are missed. If anything > seems off, I’ll flag it in #contributors or #internal-airflow-ci-cd on > Slack. If you find something that is missed, please reach out to me or on > #airflow-3-dev Slack channel. > > *Why not wait?* > > Right now, the main and v3-0-tests branches are still very close, which > makes it easier to maintain control and reduce risk. > > Using labels or backport flags doesn’t provide the same level of review or > assurance as I want to opt-in to reviewing each change then the opposite. > > This also gives us a chance to gradually clean up our `-stable` vs `-test` > branching process, which has drifted a bit in recent releases. > > I’m open to refining this if needed, but wanted to set expectations and > keep things moving cleanly into the next cycle. > > I have created https://github.com/apache/airflow/pull/49119 in preparation > for that. > > Once 3.0.0 is officially released, we’ll return to a more explicit and > automated process for backporting, similar to what we followed during the > 2.x cycle. This means PRs intended for the 3.0.x line should either be > labeled for backporting (e.g. `backport-to-v3-0-test`) or added to the > relevant bugfix milestone. I will share more details and reminders once we > are at that point. > > Thanks everyone! > > Regards, > Kaxil >
