Suggestion: just to aid that work - Kaxil - Maybe we should go back to the previous way (before cherry-picker) of marking things as ready to be cherry-picked - Marking them as "Airflow 3.0.0" milestones - this way we will make sure that some important things will not be lost ?
I think we still have the old scripts to verify if all such PRs have been merged from the milestone. We had cases like that in the past and it's very easy to miss some PRs - especially if we look at how many of those we have recently I am just a bit worried that things might fall between cracks if we do not have a mechanism for the authors or people who merge PRs to mark those PRs as "we think this one should be merged for sure". J. On Fri, Apr 11, 2025 at 4:13 PM Kaxil Naik <kaxiln...@gmail.com> wrote: > Yeah, I removed that label, too, to avoid any confusion. Once 3.0.0 is > officially released, we’ll return to `backport-to-v3-0-test` for automatic > backport -- where the PR author or a committer could do that -- but we can > discuss than once we reach there. > > 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? > > > > And yeah absolutely about the CI-related changes. I am going to keep them > updated and ask for help for sure if needed. > > On Fri, 11 Apr 2025 at 18:30, Jarek Potiuk <ja...@potiuk.com> wrote: > > > 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 > > > > > >
