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
