Yeah. Agree with Deeraj. If anything, I would rather release next version of airflowctl that will work with 3.1.7 and 3.1.8 - for 0.* version we have no promises, we can discuss some approach for later when we decide for 1.* and then starting with 3.2 support onwards would be a good choice if it costs a lot to maintain 3.1 support.
On Wed, Mar 11, 2026 at 2:24 PM Dheeraj Turaga <[email protected]> wrote: > 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 > > >
