Many thanks, Ash, for thoroughly checking and sharing your concerns and thoughts! Great points!
To provide more info to the discussion, the validation of inputs is mainly handled by Pydantic objects, based on field types and requirements. For example, we cannot add new fields or use different types. I agree that those fields shouldn't be sent to the API if they aren't provided via the CLI. If it doesn't cause any security issues, I don't think it would lead to user-facing problems since Pydantic doesn't have any flexibility on what and which things to accept. This made me think that this could be a fix to include more validation before the actual release, and I am thinking of this as a user experience rather than core functionality. Not sure if the release candidate must have this strictly I agree that the help texts are not yet fully mature, but that could indeed be a feature to add in patch versions. The underlying implementation allows us to easily update those texts through a simple mapping. I am already planning improvements in this area. This could be a worthwhile enhancement For the last part you raised, dagrun-dag command shift, pause-unpause. These are for sure a breaking change, and we cannot change until 2.0. It could make it harder for users to adopt airflowctl. I want our users to have a smooth experience when using our distributions The dag-dagrun command shift for `trigger` was because the API lists them under the `/dagRuns` endpoint. Of course, they are all under the `/dags` endpoint after all. The initial assumption was that we could move it under DagRun since it is a DagRun operation, which is creating a DagRun for a Dag. So it ended up as `dagrun trigger`. There will already be a migration effort, and some parts need to be added for auth. Making this breaking change wouldn’t be a lack of the feature, but more of which would make more sense or easier to understand under which context. The thinking was that making dag to dagrun wouldn't increase the migration effort a lot, so it was added like this to airflowctl For pause-unpause, it is breaking the 1-1 parity with the CLI and indeed can impact user adoption. We can include new features and add them easily without breaking the current behaviour before the actual release. We only need to add a couple of lines for the new commands dag pause/unpause. So we can have the RC in this case. What do you think, Ash? Of course, everything is open for discussion. I am glad we caught these ideas and things before the actual release. I wanted to share my thoughts and some thinking behind some changes Thanks a lot, Jarek, for the details of the procedure! I am completely fine with taking one step back and cancelling the voting process if irreversible changes occur between RC and the actual release that are not acceptable to PMC members On Thu, Oct 30, 2025 at 6:19 PM Jarek Potiuk <[email protected]> wrote: > Good points - let's see what others think - hopefully we get more voices. > In ideal world that discussion should have happened when we had beta > releases - but hey - better late than never :) > > On Thu, Oct 30, 2025 at 6:09 PM Ash Berlin-Taylor <[email protected]> wrote: > > > Typo: > > > > > > The reason I think these need fixing before we release is that this CLI > > interface is an API, and we shouldn’t/“can’t” change this before > airflowctl > > 2.0. > > > > > > > On 30 Oct 2025, at 17:03, Ash Berlin-Taylor <[email protected]> wrote: > > > > > > 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] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- Bugra Ozturk
