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
