Hi Bugra! Regarding airflowctl 0.1.3rc1 , I understand your position on allowing breaking changes. However, I still think we should probably re-consider releasing an rc2 with a fix because this version is not compatible with the latest airflow version that is released as of today.
If someone where to try to download airflowctl 0.1.3 today there would be no version of airflow that it would work with until 3.2.0 is officially released (which is a few weeks away) I have a small fix for this problem that should allow for getting the basic commands to work which i think we should include yo to make this release functional with the available airflow version (3.1.7) What do you think? On Mon, Mar 2, 2026 at 1:19 PM Buğra Öztürk <[email protected]> wrote: > Hi all, > > After the previous release delay caused by the same PR, I spent a few more > days reviewing the changes and found some breaking cases that were not > caught earlier. > > The main goal is to unblock backporting to v3-1-test and ensure the > datamodels are fully backwards-compatible, so we can release with > greater confidence. Some changes, like adding a new field, do not break on > the API side, but they do break for airflowctl due to extra_forbid, which > prevents newer versions from working with older schemas. This update > addresses that and introduces strict schema versioning so we can safely > support multiple core versions at the same time. It ensures not loading all > schemas for each version, but loads according to the version retrieved from > the API. This gives us flexibility to include more LoC for generated > datamodels while not slowing down the init/execution of airflowctl. With > this in mind, the CI will make it easier for us to go 1.0.0 version and > support with full control. > > As part of the setup, we now run canary on the last minor, including main, > and we added airflowctl labels for 3.1.2, 3.1.3, 3.1.5, 3.1.6, 3.1.7, and > main. Versions 3.1.0 and 3.1.1 are excluded for now due to an API server > issue after use-airflow-version, which I will check separately. The > airflowctl all versions label is integrated and versions are retrieved from > SelectiveChecks. For each new core version, adding support is only a few > lines of code. This keeps everything tested on main while maintaining > strict schema compatibility per version. We don't need to go overboard and > support entire core versions from 3.1 to 4.0. We can agree on how many core > versions we are going to support per airflowctl minor version. > > Please let me know what you think, and please review the code if you are > not fully against the idea. > > *PR:* https://github.com/apache/airflow/pull/61822 > *Main discussion points:* Strict schema versioning, how many of the core > versions to support per minor airflowctl releases > > Kind regards, > > Buğra Öztürk >
