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 >> >>
