Exactly Dheeraj. That part is not questionable :) We should at least work with the latest versions released for Airflow.
The aim of this discussion and why I created is to exactly discuss this toward 1.0 how we should manage compatibility. Maybe even have it before 1.0, so we can have gap to test the solution and incrementally improve to keep the compatibility management solid and observable starting from 1.0. Bugra Ozturk Op wo 11 mrt 2026, 17:23 schreef Jarek Potiuk <[email protected]>: > 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 > > > > > >
