You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Jarek Potiuk <ja...@potiuk.com> on 2025/11/07 00:53:36 UTC
[VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
The release candidate for **Apache Airflow Ctl**: 0.1.0rc2 is now
available for testing!
This email is calling for a vote on the release, which will last at least
until Monday the
10th of November, 2pm CET (added a bit more time to default 72 HRs) and
until 3 binding +1 votes have been received.
Consider this my +1 (binding) vote.
The apache-airflow-ctl 0.1.0rc2 package is available at:
https://dist.apache.org/repos/dist/dev/airflow/airflow-ctl/0.1.0rc2/
The "apache-airflow-ctl" packages are:
- *apache_airfow_ctl-0.1.0-source.tar.gz* is a source release that comes
with INSTALL instructions.
- *apache_airfow_ctl-0.1.0.tar.gz* is the binary Python "sdist" release.
- *apache_airfow_ctl-0.1.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 0.1.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/0.1.0/index.html
*Release Notes*:
https://github.com/apache/airflow/blob/airflow-ctl/0.1.0rc2/airflow-ctl/RELEASE_NOTES.rst
*Testing Instructions using PyPI*:
The packages are available in PyPI:
https://pypi.org/project/apache-airflow-ctl/0.1.0rc2/
You can build a virtualenv that installs this and other required packages
like this:
uv venv
uv pip install -U apache-airflow-ctl==0.1.0rc2
Regards,
Bugra and Jarek
Re: [VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
Posted by Jarek Potiuk <ja...@potiuk.com>.
On Tue, Nov 11, 2025 at 4:42 PM Ephraim Anierobi
<ep...@gmail.com> wrote:
>
> +1 binding
> Checked reproducibility, SVN, licences and signatures
>
> On Tue, 11 Nov 2025 at 15:10, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Still waiting :(
> >
> > On Mon, Nov 10, 2025 at 11:27 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > One more binding vote would be cool :)
> > >
> > > On Sat, Nov 8, 2025 at 10:40 PM Buğra Öztürk <oz...@gmail.com>
> > > wrote:
> > > >
> > > > Thanks, Jens! Exactly, we have issues (will have sub-issues to handle
> > > > multiple use cases) to address these and evolve airflowctl until 1.0.
> > We
> > > > may have even more.
> > > >
> > > > To make it visible if anyone wants to follow up :) We will approach in
> > > two
> > > > categories. Improve validation and better user-friendly errors and help
> > > > text, rather than API responses and robotic help text, and console
> > > outputs.
> > > > First is to add generic validation, such as asking for required fields
> > or
> > > > type checks and warn users accordingly [1]. We will make some
> > parameters
> > > > path parameters according to Pydantic fields, meaning they will be
> > called
> > > > `airflowctl <command> --param=value`, and they will be `airflowctl
> > > > <command> <value>`. This will include another proper validation and
> > error
> > > > handling for path parameters [2]. On the other hand, we will integrate
> > > > auto-generated commands to be able to add proper help texts and inject
> > > > custom error messages simply updating configuration files [3] [4].
> > > >
> > > > [1] https://github.com/apache/airflow/issues/57633
> > > > [2] https://github.com/apache/airflow/issues/57634
> > > > [3] https://github.com/apache/airflow/issues/57632
> > > > [4] https://github.com/apache/airflow/issues/57721
> > > >
> > > >
> > > > Thanks for the process improvements, Jarek!
> > > >
> > > > On Sat, Nov 8, 2025 at 7:08 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> > > >
> > > > > >
> > > > > > Just found the minor diff that locally the source package was named
> > > > > > apache_airflow_ctl-0.1.0rc2-source.tar.gz and SVN had it named
> > > > > > apache_airflow_ctl-0.1.0-source.tar.gz but besides the "rc2" name,
> > > the
> > > > > > files had the same content except there is rc2 in the source folder
> > > of
> > > > > > the TAR when expanding. Not blocking release in my view
> > > > > >
> > > > > >
> > > > > Not blocking indeed, but I think it also might be an artifact of us
> > > pushing
> > > > > the tag twice and lack of proper reproducibility instructions. You
> > > likely
> > > > > used locally the tag that Bugra pushed first. I then re-pushed it.
> > > Also I
> > > > > noticed that "prepare tarball" step was missing in the
> > reproducibility
> > > > > check. Previously (before my last fixes from Friday) the tarballs
> > were
> > > > > automatically prepared when --tag was used with:
> > > > >
> > > > > breeze release-management prepare-airflow-ctl-distributions
> > > > >
> > > > > You could see it when you run `git fetch apache --tags`. When I did
> > it
> > > now
> > > > > on another machine I got this:
> > > > >
> > > > > ! [rejected] airflow-ctl/1.0.0rc2 ->
> > > > > airflow-ctl/1.0.0rc2 (would clobber existing tag)
> > > > > ! [rejected] constraints-3.1.2 ->
> > > constraints-3.1.2
> > > > > (would clobber existing tag)
> > > > > ! [rejected] constraints-latest ->
> > > constraints-latest
> > > > > (would clobber existing tag)
> > > > >
> > > > > Now it needs a separate step (and this step is now properly
> > > implemented -
> > > > > i.e. it uses both VERSION_RC an VERSION - VERSION_RC is used to
> > > checkout
> > > > > the right tag, where VERSION is used to build the source tarball (we
> > > should
> > > > > never have -rcN suffix in source tarball - it's always considered as
> > > ready
> > > > > to be promoted to "final" without renaming or rebuilding.
> > > > >
> > > > > I added a PR that fixes the instructions, and adds `--force` flag to
> > > get
> > > > > the local old tag overwritten by the new one pushed with --force
> > > (which I
> > > > > did).
> > > > >
> > > > > https://github.com/apache/airflow/pull/58077
> > > > >
> > > > > Once you follow instructions from this PR - you should get
> > reproducible
> > > > > tarball (I did).
> > > > >
> > > > > J.
> > > > >
> > > >
> > > >
> > > > --
> > > > Bugra Ozturk
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org
Re: [VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
Posted by Ephraim Anierobi <ep...@gmail.com>.
+1 binding
Checked reproducibility, SVN, licences and signatures
On Tue, 11 Nov 2025 at 15:10, Jarek Potiuk <ja...@potiuk.com> wrote:
> Still waiting :(
>
> On Mon, Nov 10, 2025 at 11:27 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > One more binding vote would be cool :)
> >
> > On Sat, Nov 8, 2025 at 10:40 PM Buğra Öztürk <oz...@gmail.com>
> > wrote:
> > >
> > > Thanks, Jens! Exactly, we have issues (will have sub-issues to handle
> > > multiple use cases) to address these and evolve airflowctl until 1.0.
> We
> > > may have even more.
> > >
> > > To make it visible if anyone wants to follow up :) We will approach in
> > two
> > > categories. Improve validation and better user-friendly errors and help
> > > text, rather than API responses and robotic help text, and console
> > outputs.
> > > First is to add generic validation, such as asking for required fields
> or
> > > type checks and warn users accordingly [1]. We will make some
> parameters
> > > path parameters according to Pydantic fields, meaning they will be
> called
> > > `airflowctl <command> --param=value`, and they will be `airflowctl
> > > <command> <value>`. This will include another proper validation and
> error
> > > handling for path parameters [2]. On the other hand, we will integrate
> > > auto-generated commands to be able to add proper help texts and inject
> > > custom error messages simply updating configuration files [3] [4].
> > >
> > > [1] https://github.com/apache/airflow/issues/57633
> > > [2] https://github.com/apache/airflow/issues/57634
> > > [3] https://github.com/apache/airflow/issues/57632
> > > [4] https://github.com/apache/airflow/issues/57721
> > >
> > >
> > > Thanks for the process improvements, Jarek!
> > >
> > > On Sat, Nov 8, 2025 at 7:08 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> > >
> > > > >
> > > > > Just found the minor diff that locally the source package was named
> > > > > apache_airflow_ctl-0.1.0rc2-source.tar.gz and SVN had it named
> > > > > apache_airflow_ctl-0.1.0-source.tar.gz but besides the "rc2" name,
> > the
> > > > > files had the same content except there is rc2 in the source folder
> > of
> > > > > the TAR when expanding. Not blocking release in my view
> > > > >
> > > > >
> > > > Not blocking indeed, but I think it also might be an artifact of us
> > pushing
> > > > the tag twice and lack of proper reproducibility instructions. You
> > likely
> > > > used locally the tag that Bugra pushed first. I then re-pushed it.
> > Also I
> > > > noticed that "prepare tarball" step was missing in the
> reproducibility
> > > > check. Previously (before my last fixes from Friday) the tarballs
> were
> > > > automatically prepared when --tag was used with:
> > > >
> > > > breeze release-management prepare-airflow-ctl-distributions
> > > >
> > > > You could see it when you run `git fetch apache --tags`. When I did
> it
> > now
> > > > on another machine I got this:
> > > >
> > > > ! [rejected] airflow-ctl/1.0.0rc2 ->
> > > > airflow-ctl/1.0.0rc2 (would clobber existing tag)
> > > > ! [rejected] constraints-3.1.2 ->
> > constraints-3.1.2
> > > > (would clobber existing tag)
> > > > ! [rejected] constraints-latest ->
> > constraints-latest
> > > > (would clobber existing tag)
> > > >
> > > > Now it needs a separate step (and this step is now properly
> > implemented -
> > > > i.e. it uses both VERSION_RC an VERSION - VERSION_RC is used to
> > checkout
> > > > the right tag, where VERSION is used to build the source tarball (we
> > should
> > > > never have -rcN suffix in source tarball - it's always considered as
> > ready
> > > > to be promoted to "final" without renaming or rebuilding.
> > > >
> > > > I added a PR that fixes the instructions, and adds `--force` flag to
> > get
> > > > the local old tag overwritten by the new one pushed with --force
> > (which I
> > > > did).
> > > >
> > > > https://github.com/apache/airflow/pull/58077
> > > >
> > > > Once you follow instructions from this PR - you should get
> reproducible
> > > > tarball (I did).
> > > >
> > > > J.
> > > >
> > >
> > >
> > > --
> > > Bugra Ozturk
> >
>
Re: [VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
Posted by Jarek Potiuk <ja...@potiuk.com>.
Still waiting :(
On Mon, Nov 10, 2025 at 11:27 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> One more binding vote would be cool :)
>
> On Sat, Nov 8, 2025 at 10:40 PM Buğra Öztürk <oz...@gmail.com>
> wrote:
> >
> > Thanks, Jens! Exactly, we have issues (will have sub-issues to handle
> > multiple use cases) to address these and evolve airflowctl until 1.0. We
> > may have even more.
> >
> > To make it visible if anyone wants to follow up :) We will approach in
> two
> > categories. Improve validation and better user-friendly errors and help
> > text, rather than API responses and robotic help text, and console
> outputs.
> > First is to add generic validation, such as asking for required fields or
> > type checks and warn users accordingly [1]. We will make some parameters
> > path parameters according to Pydantic fields, meaning they will be called
> > `airflowctl <command> --param=value`, and they will be `airflowctl
> > <command> <value>`. This will include another proper validation and error
> > handling for path parameters [2]. On the other hand, we will integrate
> > auto-generated commands to be able to add proper help texts and inject
> > custom error messages simply updating configuration files [3] [4].
> >
> > [1] https://github.com/apache/airflow/issues/57633
> > [2] https://github.com/apache/airflow/issues/57634
> > [3] https://github.com/apache/airflow/issues/57632
> > [4] https://github.com/apache/airflow/issues/57721
> >
> >
> > Thanks for the process improvements, Jarek!
> >
> > On Sat, Nov 8, 2025 at 7:08 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > >
> > > > Just found the minor diff that locally the source package was named
> > > > apache_airflow_ctl-0.1.0rc2-source.tar.gz and SVN had it named
> > > > apache_airflow_ctl-0.1.0-source.tar.gz but besides the "rc2" name,
> the
> > > > files had the same content except there is rc2 in the source folder
> of
> > > > the TAR when expanding. Not blocking release in my view
> > > >
> > > >
> > > Not blocking indeed, but I think it also might be an artifact of us
> pushing
> > > the tag twice and lack of proper reproducibility instructions. You
> likely
> > > used locally the tag that Bugra pushed first. I then re-pushed it.
> Also I
> > > noticed that "prepare tarball" step was missing in the reproducibility
> > > check. Previously (before my last fixes from Friday) the tarballs were
> > > automatically prepared when --tag was used with:
> > >
> > > breeze release-management prepare-airflow-ctl-distributions
> > >
> > > You could see it when you run `git fetch apache --tags`. When I did it
> now
> > > on another machine I got this:
> > >
> > > ! [rejected] airflow-ctl/1.0.0rc2 ->
> > > airflow-ctl/1.0.0rc2 (would clobber existing tag)
> > > ! [rejected] constraints-3.1.2 ->
> constraints-3.1.2
> > > (would clobber existing tag)
> > > ! [rejected] constraints-latest ->
> constraints-latest
> > > (would clobber existing tag)
> > >
> > > Now it needs a separate step (and this step is now properly
> implemented -
> > > i.e. it uses both VERSION_RC an VERSION - VERSION_RC is used to
> checkout
> > > the right tag, where VERSION is used to build the source tarball (we
> should
> > > never have -rcN suffix in source tarball - it's always considered as
> ready
> > > to be promoted to "final" without renaming or rebuilding.
> > >
> > > I added a PR that fixes the instructions, and adds `--force` flag to
> get
> > > the local old tag overwritten by the new one pushed with --force
> (which I
> > > did).
> > >
> > > https://github.com/apache/airflow/pull/58077
> > >
> > > Once you follow instructions from this PR - you should get reproducible
> > > tarball (I did).
> > >
> > > J.
> > >
> >
> >
> > --
> > Bugra Ozturk
>
Re: [VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
Posted by Jarek Potiuk <ja...@potiuk.com>.
One more binding vote would be cool :)
On Sat, Nov 8, 2025 at 10:40 PM Buğra Öztürk <oz...@gmail.com> wrote:
>
> Thanks, Jens! Exactly, we have issues (will have sub-issues to handle
> multiple use cases) to address these and evolve airflowctl until 1.0. We
> may have even more.
>
> To make it visible if anyone wants to follow up :) We will approach in two
> categories. Improve validation and better user-friendly errors and help
> text, rather than API responses and robotic help text, and console outputs.
> First is to add generic validation, such as asking for required fields or
> type checks and warn users accordingly [1]. We will make some parameters
> path parameters according to Pydantic fields, meaning they will be called
> `airflowctl <command> --param=value`, and they will be `airflowctl
> <command> <value>`. This will include another proper validation and error
> handling for path parameters [2]. On the other hand, we will integrate
> auto-generated commands to be able to add proper help texts and inject
> custom error messages simply updating configuration files [3] [4].
>
> [1] https://github.com/apache/airflow/issues/57633
> [2] https://github.com/apache/airflow/issues/57634
> [3] https://github.com/apache/airflow/issues/57632
> [4] https://github.com/apache/airflow/issues/57721
>
>
> Thanks for the process improvements, Jarek!
>
> On Sat, Nov 8, 2025 at 7:08 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > >
> > > Just found the minor diff that locally the source package was named
> > > apache_airflow_ctl-0.1.0rc2-source.tar.gz and SVN had it named
> > > apache_airflow_ctl-0.1.0-source.tar.gz but besides the "rc2" name, the
> > > files had the same content except there is rc2 in the source folder of
> > > the TAR when expanding. Not blocking release in my view
> > >
> > >
> > Not blocking indeed, but I think it also might be an artifact of us pushing
> > the tag twice and lack of proper reproducibility instructions. You likely
> > used locally the tag that Bugra pushed first. I then re-pushed it. Also I
> > noticed that "prepare tarball" step was missing in the reproducibility
> > check. Previously (before my last fixes from Friday) the tarballs were
> > automatically prepared when --tag was used with:
> >
> > breeze release-management prepare-airflow-ctl-distributions
> >
> > You could see it when you run `git fetch apache --tags`. When I did it now
> > on another machine I got this:
> >
> > ! [rejected] airflow-ctl/1.0.0rc2 ->
> > airflow-ctl/1.0.0rc2 (would clobber existing tag)
> > ! [rejected] constraints-3.1.2 -> constraints-3.1.2
> > (would clobber existing tag)
> > ! [rejected] constraints-latest -> constraints-latest
> > (would clobber existing tag)
> >
> > Now it needs a separate step (and this step is now properly implemented -
> > i.e. it uses both VERSION_RC an VERSION - VERSION_RC is used to checkout
> > the right tag, where VERSION is used to build the source tarball (we should
> > never have -rcN suffix in source tarball - it's always considered as ready
> > to be promoted to "final" without renaming or rebuilding.
> >
> > I added a PR that fixes the instructions, and adds `--force` flag to get
> > the local old tag overwritten by the new one pushed with --force (which I
> > did).
> >
> > https://github.com/apache/airflow/pull/58077
> >
> > Once you follow instructions from this PR - you should get reproducible
> > tarball (I did).
> >
> > J.
> >
>
>
> --
> Bugra Ozturk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org
Re: [VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
Posted by Buğra Öztürk <oz...@gmail.com>.
Thanks, Jens! Exactly, we have issues (will have sub-issues to handle
multiple use cases) to address these and evolve airflowctl until 1.0. We
may have even more.
To make it visible if anyone wants to follow up :) We will approach in two
categories. Improve validation and better user-friendly errors and help
text, rather than API responses and robotic help text, and console outputs.
First is to add generic validation, such as asking for required fields or
type checks and warn users accordingly [1]. We will make some parameters
path parameters according to Pydantic fields, meaning they will be called
`airflowctl <command> --param=value`, and they will be `airflowctl
<command> <value>`. This will include another proper validation and error
handling for path parameters [2]. On the other hand, we will integrate
auto-generated commands to be able to add proper help texts and inject
custom error messages simply updating configuration files [3] [4].
[1] https://github.com/apache/airflow/issues/57633
[2] https://github.com/apache/airflow/issues/57634
[3] https://github.com/apache/airflow/issues/57632
[4] https://github.com/apache/airflow/issues/57721
Thanks for the process improvements, Jarek!
On Sat, Nov 8, 2025 at 7:08 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > Just found the minor diff that locally the source package was named
> > apache_airflow_ctl-0.1.0rc2-source.tar.gz and SVN had it named
> > apache_airflow_ctl-0.1.0-source.tar.gz but besides the "rc2" name, the
> > files had the same content except there is rc2 in the source folder of
> > the TAR when expanding. Not blocking release in my view
> >
> >
> Not blocking indeed, but I think it also might be an artifact of us pushing
> the tag twice and lack of proper reproducibility instructions. You likely
> used locally the tag that Bugra pushed first. I then re-pushed it. Also I
> noticed that "prepare tarball" step was missing in the reproducibility
> check. Previously (before my last fixes from Friday) the tarballs were
> automatically prepared when --tag was used with:
>
> breeze release-management prepare-airflow-ctl-distributions
>
> You could see it when you run `git fetch apache --tags`. When I did it now
> on another machine I got this:
>
> ! [rejected] airflow-ctl/1.0.0rc2 ->
> airflow-ctl/1.0.0rc2 (would clobber existing tag)
> ! [rejected] constraints-3.1.2 -> constraints-3.1.2
> (would clobber existing tag)
> ! [rejected] constraints-latest -> constraints-latest
> (would clobber existing tag)
>
> Now it needs a separate step (and this step is now properly implemented -
> i.e. it uses both VERSION_RC an VERSION - VERSION_RC is used to checkout
> the right tag, where VERSION is used to build the source tarball (we should
> never have -rcN suffix in source tarball - it's always considered as ready
> to be promoted to "final" without renaming or rebuilding.
>
> I added a PR that fixes the instructions, and adds `--force` flag to get
> the local old tag overwritten by the new one pushed with --force (which I
> did).
>
> https://github.com/apache/airflow/pull/58077
>
> Once you follow instructions from this PR - you should get reproducible
> tarball (I did).
>
> J.
>
--
Bugra Ozturk
Re: [VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
Posted by Jarek Potiuk <ja...@potiuk.com>.
>
> Just found the minor diff that locally the source package was named
> apache_airflow_ctl-0.1.0rc2-source.tar.gz and SVN had it named
> apache_airflow_ctl-0.1.0-source.tar.gz but besides the "rc2" name, the
> files had the same content except there is rc2 in the source folder of
> the TAR when expanding. Not blocking release in my view
>
>
Not blocking indeed, but I think it also might be an artifact of us pushing
the tag twice and lack of proper reproducibility instructions. You likely
used locally the tag that Bugra pushed first. I then re-pushed it. Also I
noticed that "prepare tarball" step was missing in the reproducibility
check. Previously (before my last fixes from Friday) the tarballs were
automatically prepared when --tag was used with:
breeze release-management prepare-airflow-ctl-distributions
You could see it when you run `git fetch apache --tags`. When I did it now
on another machine I got this:
! [rejected] airflow-ctl/1.0.0rc2 ->
airflow-ctl/1.0.0rc2 (would clobber existing tag)
! [rejected] constraints-3.1.2 -> constraints-3.1.2
(would clobber existing tag)
! [rejected] constraints-latest -> constraints-latest
(would clobber existing tag)
Now it needs a separate step (and this step is now properly implemented -
i.e. it uses both VERSION_RC an VERSION - VERSION_RC is used to checkout
the right tag, where VERSION is used to build the source tarball (we should
never have -rcN suffix in source tarball - it's always considered as ready
to be promoted to "final" without renaming or rebuilding.
I added a PR that fixes the instructions, and adds `--force` flag to get
the local old tag overwritten by the new one pushed with --force (which I
did).
https://github.com/apache/airflow/pull/58077
Once you follow instructions from this PR - you should get reproducible
tarball (I did).
J.
Re: [VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
Posted by Jens Scheffler <js...@apache.org>.
+1 (binding) - Checked SVN, Checksums, Reproducible package build,
Licenses, Signatures
Just found the minor diff that locally the source package was named
apache_airflow_ctl-0.1.0rc2-source.tar.gz and SVN had it named
apache_airflow_ctl-0.1.0-source.tar.gz but besides the "rc2" name, the
files had the same content except there is rc2 in the source folder of
the TAR when expanding. Not blocking release in my view.
Good to be released!
Some usability glitches I had by naively monkey testing:
- Used "airflowctl pools get" (assuming it is the same like "kubectl get
pods" but needed to realize that I need to use list. Got the error
extra={'detail': 'The Pool with name: `None` was not found'} - might be
better to either list instead or validate on CLI
- Same with "dags get", got "extra={'detail': 'The Dag with ID: `None`
was not found'}" and probably CLI validation for other commands as well
So might be good to evolve a bit before it gets a 1.0.
On 11/7/25 03:15, Buğra Öztürk wrote:
> Thanks, Jarek! +1 non-binding
>
> On Fri, Nov 7, 2025 at 1:53 AM Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> The release candidate for **Apache Airflow Ctl**: 0.1.0rc2 is now
>> available for testing!
>>
>> This email is calling for a vote on the release, which will last at least
>> until Monday the
>> 10th of November, 2pm CET (added a bit more time to default 72 HRs) and
>> until 3 binding +1 votes have been received.
>>
>> Consider this my +1 (binding) vote.
>>
>> The apache-airflow-ctl 0.1.0rc2 package is available at:
>> https://dist.apache.org/repos/dist/dev/airflow/airflow-ctl/0.1.0rc2/
>>
>> The "apache-airflow-ctl" packages are:
>>
>> - *apache_airfow_ctl-0.1.0-source.tar.gz* is a source release that comes
>> with INSTALL instructions.
>> - *apache_airfow_ctl-0.1.0.tar.gz* is the binary Python "sdist" release.
>> - *apache_airfow_ctl-0.1.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 0.1.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/0.1.0/index.html
>>
>> *Release Notes*:
>>
>> https://github.com/apache/airflow/blob/airflow-ctl/0.1.0rc2/airflow-ctl/RELEASE_NOTES.rst
>>
>> *Testing Instructions using PyPI*:
>>
>> The packages are available in PyPI:
>> https://pypi.org/project/apache-airflow-ctl/0.1.0rc2/
>>
>> You can build a virtualenv that installs this and other required packages
>> like this:
>>
>> uv venv
>> uv pip install -U apache-airflow-ctl==0.1.0rc2
>>
>> Regards,
>>
>> Bugra and Jarek
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org
Re: [VOTE] Release Airflow CTL 0.1.0 from 0.1.0rc2
Posted by Buğra Öztürk <oz...@gmail.com>.
Thanks, Jarek! +1 non-binding
On Fri, Nov 7, 2025 at 1:53 AM Jarek Potiuk <ja...@potiuk.com> wrote:
> The release candidate for **Apache Airflow Ctl**: 0.1.0rc2 is now
> available for testing!
>
> This email is calling for a vote on the release, which will last at least
> until Monday the
> 10th of November, 2pm CET (added a bit more time to default 72 HRs) and
> until 3 binding +1 votes have been received.
>
> Consider this my +1 (binding) vote.
>
> The apache-airflow-ctl 0.1.0rc2 package is available at:
> https://dist.apache.org/repos/dist/dev/airflow/airflow-ctl/0.1.0rc2/
>
> The "apache-airflow-ctl" packages are:
>
> - *apache_airfow_ctl-0.1.0-source.tar.gz* is a source release that comes
> with INSTALL instructions.
> - *apache_airfow_ctl-0.1.0.tar.gz* is the binary Python "sdist" release.
> - *apache_airfow_ctl-0.1.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 0.1.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/0.1.0/index.html
>
> *Release Notes*:
>
> https://github.com/apache/airflow/blob/airflow-ctl/0.1.0rc2/airflow-ctl/RELEASE_NOTES.rst
>
> *Testing Instructions using PyPI*:
>
> The packages are available in PyPI:
> https://pypi.org/project/apache-airflow-ctl/0.1.0rc2/
>
> You can build a virtualenv that installs this and other required packages
> like this:
>
> uv venv
> uv pip install -U apache-airflow-ctl==0.1.0rc2
>
> Regards,
>
> Bugra and Jarek
>
--
Bugra Ozturk