kaxil commented on code in PR #50539: URL: https://github.com/apache/airflow/pull/50539#discussion_r2086895934
########## contributing-docs/19_execution_api_versioning.rst: ########## @@ -0,0 +1,94 @@ + .. Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + +Execution API Versioning +======================== + +Airflow's Task Execution API uses `Cadwyn <https://github.com/zmievsa/cadwyn>`_ for API versioning with CalVer. +This allows us to maintain backward compatibility while evolving the API over time. + +Why? +---- + +Airflow components (e.g., workers, API servers) could be deployed independently. This can lead +to version mismatches—for example, a worker using Task SDK 1.0.1 (requiring Airflow >=3.0.1) while the +API server is still on 3.0.0. Without versioning, such mismatches can cause runtime failures or subtle bugs. +A strict versioning model allows older clients to continue working with newer servers, enabling safe, incremental upgrades. + +Versioning Principles +--------------------- + +1. Any change to the API schema or behavior that affects existing clients requires a new version. +2. All versions are maintained in the codebase +3. Migrations encapsulate all schema changes. +4. Core code logic remains version-agnostic. + +Version Changes +--------------- + +When making changes to the Execution API, you must: + +1. Add a new migration module (e.g., ``v2025_04_28.py``). +2. Document the changes in the migration. +3. Update tests to cover both old and new versions. +4. Ensure backward compatibility wherever possible. + +Example Version Migration +------------------------- + +Here's an example of how to add a new version migration: Review Comment: aah got it, let me add that -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
