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 clearly "just failing because it might not be good to make this.change" - however we could either set a special label on such PRs (to avoid the error) or just merge it with "red" status.
Not critical though. It could also be based on reviews. J. On Wed, Sep 4, 2024 at 3:46 PM Brent Bovenzi <br...@astronomer.io.invalid> wrote: > 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 a > transition time while we get both new projects feature-complete. > > This means that sometimes we will still have to accept changes to the > `airflow/www` javascript files, `airflow/www/views.py` webserver endpoints > and `airflow/api_connexion` rest API endpoints. But we want to limit > contributions to "legacy" code which will be deleted in a few short > months. Which > is specified here in the Airflow docs. > <https://github.com/apache/airflow/pull/41903> > > 1. Bug fixes to cherry pick for 2.10.x and 2.11 > 2. The minimum necessary to unblock other Airflow 3.0 feature work > 3. Fixes to views and endpoints which we haven't migrated over yet, but can > still be ported over to the new UI > > For example, we will not migrate the legacy UI to use the new REST API. > This means that, for a time, we will have duplicate code (ex: two different > grid_data endpoints). But this reduces the surface area that we must > maintain and allows us to redesign views and endpoints when necessary (ex: > making the grid_data more efficient and to better support DAG versioning). > > We see three phases to migrating to the UI: > 1. New UI has very few features. Show a dismissible banner to "Check out > the new UI" > 2. New UI has most of the core features of Airflow. Make the new UI the > default, and link to the legacy UI as an escape hatch. What is sufficient > for "core features" is to be determined. > 3. New UI is fully feature-complete, delete the entire legacy UI project. > > Let me know what you all think. I am happy to discuss more on the dev call > tomorrow. > > - Brent >
