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
