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