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

Reply via email to