Hey Ash, Thanks for raising your concerns! Indeed those are auto generated. We have Assets, Dags where you concerned from there. You can see all commands with pictures (group and actions commands and list). Pictures: https://airflow.apache.org/docs/apache-airflow-ctl/stable/howto/index.html#all-available-group-command-references List: https://airflow.apache.org/docs/apache-airflow-ctl/stable/cli-and-env-variables-ref.html#dags
For the one we added for 3.3 indeed needs to be added. We are working on them for example like below. https://github.com/apache/airflow/pull/68564 For airflowctl I think we should focus more on if airflowctl is mature enough for 1.0 rather full feature parity with core if that make sense. The main concerns with 1.0 was mainly user validation, help texts, compatibility, etc. What do you think? --- Some context over parity with core, one huge con adding the same functionalities into two place is keeping them fully sync is nearly impossible. If we won't add airflowctl while adding CLI commands or deprecate and putt all effort in airflowctl, we would never reach to that state. I can say last year the chaising of airflowctl to core to start AIP-94 ended up with the same result of airflowctl have missing ones that customly implemented in core. Any new addition to datamodels to existing commands such as Assets partitions should automatically cascaded into airflowctl from auto generated but if we implemented specifically like Dag state one, those we can easily cover when we stop developing on CLI (which we are trying even without) and put the effort on airflowctl. This is what we are trying with AIP-94, stop development via deprecation warnings in core cli commands and use airflowctl methods. If new command doesn't exists like state command, we will add like above PR and then migrate with separate PR. This part can go incrementally as I assume we already have more offering in ctl but ones added to core specifically will stop with the deprecations Best regards, Bugra Ozturk Op di 16 jun 2026, 12:13 schreef Ash Berlin-Taylor <[email protected]>: > I don’t think we quite are there yet — unless I missed something, there is > no `dags list` command? > https://github.com/apache/airflow/blob/main/airflow-ctl/src/airflowctl/ctl/cli_config.py#L961-L989 > - maybe it’s autogenerated? > > There is also nothing to do with Assets in airflowctl(?) so we’ll need to > add that, and probably equally deadline alerts, and anything else added in > 3.1 or 3.2, and given 3.3 is in the final stages, anything in 3.3 such as > Task/Asset State Storage, and possibly Asset Partitions > > -ash > > > On 11 Jun 2026, at 18:53, Buğra Öztürk <[email protected]> wrote: > > > > Hi all, > > > > When we introduced airflowctl under AIP-81 / AIP-94 [1][2], the stated > > direction was to reach 1.0.0 "step by step". We shipped 0.1.0 in Nov 2025 > > and are now at 0.1.5, with broad feature coverage and a CLI grammar that > > has settled (required params positional, optional ones as flags, per the > > parameter-style lazy consensus [3]). I think it is time to take that step > > and release 1.0.0. > > > > Concretely, 1.0.0 would put the user-facing CLI surface under SemVer, > with > > deprecations following the same policy as Airflow itself. > > > > One more thing worth discussing is the coupling with core. Airflow core > now > > depends on apache-airflow-ctl with a pinned version range, and the client > > datamodels are generated from the core API. Jarek suggested earlier that > > releasing the two together could make this easier with TaskSDK, which > feels > > worth considering as it can provide strict versioning between releases > but > > easier maintenance between release cycles to one catch another all the > > time. Therefore, I would like to hear what people think about keeping > > airflowctl on its own cadence versus aligning the 1.0.0 cut with a core > > release. This could also help combine release manager effort and reduce > > overall release coordination overhead. > > > > We plan to start the release vote at the end of June, so please share any > > objections or thoughts before then. The additional combined distribution > > part is not a hard dependency. We can proceed with a couple of iterations > > and evaluate the results as we go. If there is no strong agreement on > this > > idea, we will continue with separate release cycles. > > > > > > [1] AIP-81: > > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-81+Enhanced+Security+in+CLI+via+Integration+of+API > > [2] AIP-94: > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=382175838 > > [3] Parameter style lazy consensus: > > https://lists.apache.org/thread/m1qvcvow3l17ytv40vhslh40wn3rntrm > > > > Thanks, > > Best regards, > > Bugra Ozturk > >
