ashb commented on code in PR #50539: URL: https://github.com/apache/airflow/pull/50539#discussion_r2086792005
########## 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``). Review Comment: We probably need to say what version to set this as. I think there are two options. 1. Pick a likely date for when it'll be released (and then only change it if we need two, so for example in Amogh's latest PR example he picked "2025-05-20" cos that's about when 3.0.2 will be released. 2. Pick a "far future date", so for example "2199-12-31" and then always fix up the date before release. I think 1 is a better approach, but we should say what to do. Oh also, if there is an unreleased version you can add a new migration to the existing latest version too -- each migration doesn't need a unique version in other words. -- 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]
