Thanks Brent. Yes I like the idea of labels, I believe this will help reviewers know that they have to pay extra attention because specific rules apply to updating the legacy-ui/api during airflow 3 development.
An automated test is even better but might be more effort to develop. On Wed, Sep 4, 2024 at 10:34 PM Buğra Öztürk <ozturkbugr...@gmail.com> wrote: > Thanks for preparing! I think making this distinction between legacy and > new UI is beneficial for us. It will make it easy to break and change > things. The plan looks great! > > Great point Jarek. Even though it's not critical, I think it would be > beneficial for everyone to see the PR editing the legacy code pieces. > Maybe, we can include a set of labels (like legacy-ui, legacy-api or > some-label...) by using boring-cyborg powers to auto-label certain legacy > code pieces. > > On Wed, Sep 4, 2024 at 4:37 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > 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 > > > > > > > > -- > Bugra Ozturk >
