To re-emphasise, my reason for voting -1 on this is the incorrect client side error handling.
The fact that you can run commands such as `airflowctl dagrun list` or `airflowctl dags update` and there is 0 client side validation of requirements that should be required is the primary reason. Though the more I play with it, I also think this is too close to a CLI around the API client, and not quite a tool designed for users itself. - For instance, to trigger a dag, the command is `airflow dagrun trigger —dag-id dag1` — which is where the API places this operation, but this surprised me. Both the UI and the old `airflow` cli had this under `dag`, so I expected `airflow dag trigger` to be an operation - There is no direct command to pause or unpause a dag, instead you have to do `airflowctl dags update --no-is-paused --dag-id dag1`. Issues here: 1. Pause and unpause are very common operations, and should have their own command. 2. `no-is-paused` is a clunky interface. - Passing the (semi-)required dag id via a cli option `—dag-id` rather than positional. I.e. I’d expect `airflow dags unpause dag1` to be how the command is invoked, not `airflow dags unpause —dag-id dag1`. The reason I think these need fixing before we release is that this CLI interface is an interface, and we shouldn’t/“can’t” change this before airflowctrl 2.0. -ash > On 30 Oct 2025, at 16:46, Jarek Potiuk <[email protected]> wrote: > > Thanks Ash for doing more thorough checks! Really cool. > > Just to clarify things - as an educational exercise for the community - we > have many new members in the community and they might not realise how > releases work, so I wanted to use that opportunity to explain. > > Releases may not be vetoed. It's always majority release - It's enough to > have 3 +1s from PMC members and more + than - from PMC members: > https://www.apache.org/foundation/voting.html#ReleaseVotes . The voting > policy says that: > >> Generally the community will cancel the release vote if anyone identifies > serious problems, but in most cases the ultimate decision lies with the > individual serving as release manager. The specifics of the process may > vary from project to project, but the 'minimum quorum of three +1 votes' > rule is universal. > > So if we generally - in the community - agree (and I would love to hear > more voices) that issue is serious enough we might cancel the vote. I think > it would be actually great if more people - like Ash - from the community > would take airflow-ctl for a spin and report here with their (even > non-binding) voices. This is the first time we are releasing it, and I > think it's worth doing a more thorough check. > > I personally don't really think clarity of messages is "serious" enough to > stop releasing. We released airflow multiple times with way, way, way less > clear error messages in many places. But it's not strong of course. We > could argue whether it's fine to do validation in both - client and server > or whether it's enough to have a server doing validation - both solutions > have pros and cons. And we could agree on either approach. But that's > likely topic for another discussion - here it's more "is the current > approach good-enough to make it an official release". > > But since I am acting just as PMC "driving" the release and practically > speaking - Bugra is the Release Manager not me, I am absolutely happy with > whatever he decides - it's his call to cancel the vote if we think it's not > good enough (or we might simply not see a possibility of getting 3 +1s or > have more -1s from PMCs, then PMC members will decide). > > J. > > > On Thu, Oct 30, 2025 at 5:13 PM Ash Berlin-Taylor <[email protected]> wrote: > >> Not quite -1 worth by itself, but the help message isn’t great either — >> "state for list operation in DagRunOperations” is… not a great help >> message. My expectation is that airflowctl would be more than a shim on the >> API, and as such it should have standalone useful help messages >> >> >> ``` >> Options: >> -h, --help show this help message and exit >> --dag-id DAG_ID dag_id for list operation in DagRunOperations >> --end-date END_DATE end_date for list operation in DagRunOperations >> -e, --env ENV The environment to run the command in >> --limit LIMIT limit for list operation in DagRunOperations >> --start-date START_DATE >> start_date for list operation in DagRunOperations >> --state STATE state for list operation in DagRunOperations >> --output, -o (table, json, yaml, plain) >> Output format. Allowed values: json, yaml, plain, >> table (default: json) >> ``` >> >>> On 30 Oct 2025, at 16:10, Ash Berlin-Taylor <[email protected]> wrote: >>> >>> -1 This isn’t ready for release yet I’m afraid. >>> >>> The CLI doesn’t do nearly enough validation of arguments: >>> >>> ``` >>>> airflowctl dagrun list >>> 2025-10-30 16:09:33 [warning ] Server error >> [airflowctl.api.client] extra={'detail': 'Invalid value for state. Valid >> values are queued, running, success, failed'} >>> Server response error: Client error message: {'detail': 'Invalid value >> for state. Valid values are queued, running, >>> success, failed'} >>> Client error, Please check the command and its parameters. If you need >> help, run the command with —help. >>> ``` >>> >>> And the request that is making is `GET >> /api/v2/dags/None/dagRuns?start_date=&end_date=&state=&limit=&dag_id` >>> >>> That shouldn’t be passing any of the query arguments in that case. >>> >>> I will continue testing and report what I find, but right now we’re not >> there yet >>> >>> -ash >>> >>>> On 29 Oct 2025, at 20:42, Jens Scheffler <[email protected]> wrote: >>>> >>>> Thanks Jarek for the hint as well as preparing the release! >>>> >>>> +1 (binding) - Checked SVN, Checksums, Reproducible package build, >> Licenses, Signatures >>>> >>>> Opened PR https://github.com/apache/airflow/pull/57513 to add the >> missing cli argument to docs. >>>> >>>> On 28.10.25 23:31, Jarek Potiuk wrote: >>>>> Should be `--version 1.0.0rc2` added to the command. >>>>> >>>>> On Tue, Oct 28, 2025 at 11:11 PM Jens Scheffler <[email protected]> >> wrote: >>>>> >>>>>> Followed the release checking guide and wanted to validate as my PMC >>>>>> duty but got the following error: >>>>>> >>>>>> (airflow) jscheffl@hp860g9:~/Workspace/airflow$ breeze >>>>>> release-management prepare-airflow-tarball --distribution-name >>>>>> apache_airflow_ctl >>>>>> Creating tarball for apache_airflow_ctl airflow-ctl/1.0.0 >>>>>> fatal: not a valid object name: airflow-ctl/1.0.0 >>>>>> Failed to create tarball >>>>>> >> /home/jscheffl/Workspace/airflow/out/apache_airflow_ctl-1.0.0-source.tar.gz >>>>>> >>>>>> for Apache apache_airflow_ctl airflow-ctl/1.0.0 >>>>>> (airflow) jscheffl@hp860g9:~/Workspace/airflow$ git status >>>>>> HEAD detached at airflow-ctl/1.0.0rc2 >>>>>> nothing to commit, working tree clean >>>>>> >>>>>> Any idea/guidance? Is this a teething breeze bug? >>>>>> >>>>>> On 28.10.25 07:54, Amogh Desai wrote: >>>>>>> Really nice to see this one fold in so quickly! >>>>>>> >>>>>>> Great amount of effort, Bugra and Jarek! >>>>>>> >>>>>>> Thanks & Regards, >>>>>>> Amogh Desai >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 28, 2025 at 6:06 AM Buğra Öztürk < >> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Wohooo! +1 non-binding >>>>>>>> >>>>>>>> Again and again couldn't share my good feelings. Amazing community, >> many >>>>>>>> thanks everyone being there for support, implement, test, release, >> for >>>>>>>> everything 🎉🎉🙏 >>>>>>>> >>>>>>>> Bugra Ozturk >>>>>>>> >>>>>>>> On Mon, 27 Oct 2025, 23:01 Jarek Potiuk, <[email protected]> wrote: >>>>>>>> >>>>>>>>> The release candidate for **Apache Airflow Ctl**: 1.0.0rc2 is now >>>>>>>>> available for testing! >>>>>>>>> >>>>>>>>> This email is calling for a vote on the release, which will last at >>>>>> least >>>>>>>>> until the >>>>>>>>> 23:00 CET, Friday, October 30, 2025 and until 3 binding +1 votes >> have >>>>>>>> been >>>>>>>>> received. >>>>>>>>> >>>>>>>>> Consider this my +1 (binding) vote. >>>>>>>>> >>>>>>>>> The apache-airflow-ctl 1.0.0rc2 package is available at: >>>>>>>>> >> https://dist.apache.org/repos/dist/dev/airflow/airflow-ctl/1.0.0rc2/ >>>>>>>>> >>>>>>>>> The "apache-airflow-ctl" packages are:: >>>>>>>>> >>>>>>>>> - *apache_airfow_ctl-1.0.0-source.tar.gz* is a source release >> that >>>>>>>> comes >>>>>>>>> with INSTALL instructions. >>>>>>>>> - *apache_airfow_ctl-1.0.0.tar.gz* is the binary Python "sdist" >>>>>>>> release. >>>>>>>>> - *apache_airfow_ctl-1.0.0-py3-none-any.whl* is the binary >> Python >>>>>>>> wheel >>>>>>>>> "binary" release. >>>>>>>>> >>>>>>>>> Public keys are available at: >>>>>>>>> https://dist.apache.org/repos/dist/release/airflow/KEYS >>>>>>>>> >>>>>>>>> Please vote accordingly: >>>>>>>>> >>>>>>>>> [ ] +1 approve >>>>>>>>> [ ] +0 no opinion >>>>>>>>> [ ] -1 disapprove with the reason >>>>>>>>> >>>>>>>>> Only votes from PMC members are binding, but all members of the >>>>>> community >>>>>>>>> are encouraged to test the release and vote with "(non-binding)". >>>>>>>>> >>>>>>>>> The test procedure for PMC members is described in: >>>>>>>>> >>>>>>>>> >>>>>> >> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOWCTL.md#verify-the-release-candidate-by-pmc-members >>>>>>>>> The test procedure for contributors and members of the community >> who >>>>>>>> would >>>>>>>>> like to test this RC is described in: >>>>>>>>> >>>>>>>>> >>>>>> >> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOWCTL.md#verify-the-release-candidate-by-contributors >>>>>>>>> Please note that the version number excludes the 'rcX' string, so >> it's >>>>>>>> now >>>>>>>>> simply 1.0.0 for the apache-airflow-ctl package. >>>>>>>>> This will allow us to rename the artifact without modifying the >>>>>> artifact >>>>>>>>> checksums when we actually release. >>>>>>>>> >>>>>>>>> *Docs* (for preview): >>>>>>>>> >>>>>> >> https://airflow.staged.apache.org/docs/apache-airflow-ctl/1.0.0/index.html >>>>>>>>> *Release Notes*: >>>>>>>>> >>>>>>>>> >>>>>> >> https://github.com/apache/airflow/blob/airflow-ctl/1.0.0rc2/airflow-ctl/RELEASE_NOTES.rst >>>>>>>>> *Testing Instructions using PyPI*: >>>>>>>>> >>>>>>>>> The packages are available in PyPI: >>>>>>>>> https://pypi.org/project/apache-airflow-ctl/1.0.0rc2/ >>>>>>>>> >>>>>>>>> You can build a virtualenv that installs this and other required >>>>>> packages >>>>>>>>> like this: >>>>>>>>> >>>>>>>>> uv venv >>>>>>>>> uv pip install -U apache-airflow-ctl==1.0.0rc2 >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Jarek & Bugra >>>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
