> It will likely work fine if we do some "consistency check" when FAB is
used
as "external_db_manager" - in this case, possibly airflow should refuse to
start (and show helpful message) if there is a consistency problem between
what FAB expects and what is stored in alembic DB. This should handle a
Hi all,
As part of AIPs 38, 79 and 84, Pierre and I have started a new API based on
FastAPI and a new UI based purely off of React. The current UI, rest API
and webserver endpoints will now be considered "legacy" and will be
completely removed by the time Airflow 3.0 is released. But there will be
I like the plan in its entirety.
Some technicalities - likely we do not want to automate what is / is not
allowed - managing it might be difficult, but we could as well add some
separate non-critical / failing test that will "fail" when the "old" area
is touched in the PR (but it could be very cle
Hey All,
Here are the minutes, recording, and deck from our September 4th Airflow
Town Hall! <
https://docs.google.com/document/d/1BAvSH31B66BRHIrxvK_cILhm0W9bQYw4gDSakmNdiNw/edit?usp=sharing
>
I'm grateful to Jed Cunningham, Josix Wang, Kaxil Naik, Jens Scheffler and
Igor Kholopov for presenting
Hi all,
As discussed in
https://lists.apache.org/thread/7jf12p2mk0nr5495f26r67gnpm3jq8oj I am
calling for a lazy consensus on using marking 2.11 as a bridge release with
the following ideas:
1. It would only have bug fixes & deprecation warnings as a BRIDGE
release -- NO features. The exce
Hi Kaxil,
+1 binding. With the assumption that AIP-80 was voted I assume we planned to
introduce the new templating early. This would be (in my eyes except we see
other things we need to mark deprecated to need to add features for migration
preparation) the demand for Airflow 2.11
Jens
Sent f
