We should wait to complete the entire decoupling story imo including AIP-92. Until then there won’t be a any net benefit. So 3.3 would be the earliest for this — mid next year.
On Mon, 5 Jan 2026 at 10:01, Pierre Jeambrun <[email protected]> wrote: > Sounds good to me. > > Just a technicality, in the api_fastapi folder we already have `core_api` > (public + UI) and `execution_api`. This sub structure wouldn't make sense > anymore, `airflow.core.api_fastapi.core_api`. (all 3 are core server > component I guess) > > On Mon, Jan 5, 2026 at 10:49 AM Aritra Basu <[email protected]> > wrote: > > > +1 from me for the thought, Agree with Jens on this as well, if we're > > cleaning up let's also take the opportunity to move them under components > > too! > > > > -- > > Regards, > > Aritra Basu > > > > On Mon, 5 Jan 2026, 3:04 pm Rahul Vats, <[email protected]> wrote: > > > > > +1 to this. Clear namespace boundaries will definitely help folks > > > understand what depends on what. Agree with Jens on organizing by > server > > > component too. > > > > > > Regards, > > > Rahul Vats > > > > > > On Mon, 5 Jan 2026 at 14:02, Jens Scheffler <[email protected]> > wrote: > > > > > > > Hallo Amogh, > > > > > > > > that totally makes sense to get the "house clean" and separate. > > > > > > > > If we are moving all server components anyway, would it make sense to > > > > then define namespaces per server component below airflow.core. > > directly > > > > such that a future separation into API server/scheduler/dag parser > can > > > > keep a moved structure? > > > > > > > > e.g. moving all API server specific stuff to airflow.core.api. and > all > > > > scheduler specific to airflow.core.scheduler. > > > > > > > > Jens > > > > > > > > On 1/5/26 09:17, Amogh Desai wrote: > > > > > Hello All, > > > > > > > > > > Wishing you all a happy new year and hope you spent good time with > > your > > > > > loved ones. > > > > > > > > > > With the ongoing efforts on Airflow Client Server separation, I > > figured > > > > > that this would be a > > > > > good time to discuss a proposal in a similar vein to those efforts. > > > > > > > > > > I'd like to propose establishing an `airflow.core.*` module > namespace > > > for > > > > > server-only components > > > > > as part of our AIP-72 client-server separation work. > > > > > > > > > > *What:* > > > > > Move server-specific modules(API, scheduler, migrations, ORMs, and > > > more) > > > > > that are specifically > > > > > used by the server components, to a new `airflow.core.*` namespace. > > > > > > > > > > For example: > > > > > - airflow.models.* → airflow.core.models.* > > > > > - airflow.jobs.* → airflow.core.jobs.* > > > > > - airflow.api_fastapi.* → airflow.core.api.* (or retain > > `api_fastapi`) > > > > > > > > > > Backward compatibility would be maintained for the older paths with > > > some > > > > > tooling that we already > > > > > have > > > > > < > > > > > > > > > > https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/utils/deprecation_tools.py > > > > > > > > > > by > > > > > issuing deprecation warnings and providing users with a clear > > > > > migration path. > > > > > > > > > > *Why:* > > > > > AIP-72 separates airflow into server and client components, but > today > > > > there > > > > > is no way to tell from > > > > > an import path whether the code is intended to be server only or > > client > > > > > only, or shared(shared is > > > > > still better). This makes it easy to accidentally couple components > > > that > > > > > should be independent. > > > > > We have some prek hooks in place to avoid this as much as possible, > > but > > > > > there is a limit to how much > > > > > we can restrict. > > > > > > > > > > Moving the server code to `airflow.core.*` would make the boundary > > much > > > > > clearer. The end goal would > > > > > look like: > > > > > - airflow.core.* = server-only > > > > > - airflow.sdk.* = client-side > > > > > - airflow._shared.* = shared between both > > > > > > > > > > It would also bring in some added benefits: > > > > > 1. Self documenting architecture: the import paths would now reveal > > > > > dependencies between > > > > > components > > > > > 2. Reduced accidental coupling > > > > > > > > > > We already have two issues in place to track this: > > > > > 1. https://github.com/apache/airflow/issues/51554 > > > > > 2. https://github.com/apache/airflow/issues/51555 > > > > > > > > > > I have deliberately not listed the estimate of efforts here to > agree > > on > > > > the > > > > > approach first. > > > > > I would love to hear what folks think about this approach until > > > Saturday: > > > > > > > > > > > > > > > https://www.timeanddate.com/worldclock/fixedtime.html?msg=Voting+ends&iso=20260110T0830&p1=1440 > > > > > and will start a lazy consensus after that. > > > > > > > > > > Thanks & Regards, > > > > > Amogh Desai > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > >
