Thanks for sending this out, Ash. Yeah I agree with you and Jarek about the 3.1 work items. It would also be nicer to get some more support from the community who are working on "not so critical" 3.1 or later items, just so that they can get some window to develop it while 3.0 is underway.
Another small note to the committers merging PRs, use your judgement to sometimes run full tests on some PRs that could potentially impact certain other areas and cause the canaries to fail later. (We all have limited time and sometimes it's not too easy to debug the cause of the canaries). For example: https://github.com/apache/airflow/actions/runs/13158509534 and https://github.com/apache/airflow/actions/runs/13068324349 were not easy ones to debug and took some time and effort :) Thanks & Regards, Amogh Desai On Fri, Feb 7, 2025 at 5:32 PM Jarek Potiuk <ja...@potiuk.com> wrote: > And just to clarify what I personally think of a social / community effect > here and be very blunt about it - sorry for those who might find it harsh > > I personally think it is good that there is more (personal) friction to > work on 3.1 related features than working on making Airflow 3.0 a success. > Deliberately. > > We have a lot of volunteers, people who decide on their own where they > spend their time. Whoever wants to work on 3.1 features now, they are cool > to do that, but they have to bear the "consequences" of it - i.e. they will > have friction with whatever community develops for Airflow 3.0. This should > be built-in to the current "setup" . That might give those people who want > to spend their time more incentive in helping to make Airflow 3.0 a > success. There will be plenty of "dull" and not very challenging tasks, > issues, testing, documentation to do that a lot of people could do. It > should be easier and more rewarding to do so, than to develop 3.1 features > so that they could - on their own - make a decision to spend their time on > helping with 3.0 more likely. > > I think eventually the community will benefit from that. > > J. > > > On Fri, Feb 7, 2025 at 12:55 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > Agree with Ash. 100% focus on what we want to do for Airflow 3 first. If > > anyone wants to work on Airflow 3.1 features, they could work in their > own > > branches/forks and keep rebasing it. > > > > J. > > > > > > On Fri, Feb 7, 2025 at 10:22 AM Ash Berlin-Taylor <a...@apache.org> > wrote: > > > >> We “could", but creating a branch for 3.1 will be an absolute nightmare > >> to keep it up to date with main and it will conflict almost every day. > I’m > >> not touching that with someone else’s bargepole. > >> > >> In short: best not to work on anything for 3.1 yet as there’s nowhere we > >> can merge it to that doesn’t require constant maintenance. > >> > >> -ash > >> > >> > On 7 Feb 2025, at 02:23, Wei Lee <weilee...@gmail.com> wrote: > >> > > >> > Do we need to create a branch for 3.1+ features? So that we can still > >> merge them instead of making them stale (not sure whether there’s anyone > >> already working on new features before this announcement 🤔) > >> > > >> > Best, > >> > Wei > >> > > >> >> On Feb 7, 2025, at 7:17 AM, Vikram Koka <vik...@astronomer.io.INVALID > > > >> wrote: > >> >> > >> >> Thanks for sending this out, Ash. > >> >> > >> >> On Thu, Feb 6, 2025 at 6:10 AM Ash Berlin-Taylor <a...@apache.org> > >> wrote: > >> >> > >> >>> Hi all, > >> >>> > >> >>> A reminder and notice to all committers: now that we have cut the > >> first > >> >>> alpha version of Airflow 3.0 please be extra careful about what you > >> merge > >> >>> to main. Please don’t merge any new features to core airflow. > >> >>> > >> >>> Changes to Providers can carry on as usual (or at least 99% of them > >> will > >> >>> be) but please be thoughtful about what we merge to the main airflow > >> code > >> >>> base. I would suggest being careful with Provider changes to be > aware > >> of no > >> >>> more direct DB access. > >> >>> > >> >>> What exactly counts as a feature? Please use your judgement. The > >> purpose > >> >>> of this feature freeze is to make it realistic to test all the > changes > >> >>> without chasing a moving target. In short: if there’s even a chance > >> that it > >> >>> could jeopardise the release please hold off merging it until after > >> 3.0.0 > >> >>> is released. Obvioulsy that gets riskier the closer we get to the RC > >> >>> cut-off date (which will be end of March 2025). > >> >>> > >> >>> This freeze doesn’t apply to current in-progress AIPs (such as 38 - > >> new > >> >>> ui, 72 - Task SDk, or 82 - event driven scheduling) but is mostly > >> around > >> >>> non-AIP features or AIPs that are marked for 3.1+. As we get closer > to > >> >>> release, this needs to get tighter across the board, since we will > >> need to > >> >>> get more risk-averse in order to release a stable, quality product. > >> >>> > >> >>> Thanks, > >> >>> Ash > >> >>> > --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > >> >>> For additional commands, e-mail: dev-h...@airflow.apache.org > >> >>> > >> >>> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > >> > For additional commands, e-mail: dev-h...@airflow.apache.org > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > >> For additional commands, e-mail: dev-h...@airflow.apache.org > >> > >> >
