Apache Airflow 版本策略与发布流程全解析SemVer、发布分支与弃用机制【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflowApache Airflow 从 2.0.0 与 Providers 1.0.0 起全面遵循语义化版本SemVer规范构建起一套覆盖版本号管理、发布分支、弃用策略与实验性特性治理的完整发布体系。本文以 airflow-core/docs/release-process.rst 为骨架结合仓库内的发布工具链Breeze、可复现构建配置与源码实现系统讲解 Airflow 的版本策略与发布流程。读完本文你将理解 Airflow 的版本号如何解读、补丁版本为何值得无条件升级、弃用特性如何分阶段移除以及实验性特性为何可以随时推翻重来。一、SemVer 版本策略X.Y.Z 三个数字各自代表什么Airflow 的版本号严格采用X.Y.Z三段式结构三段数字各有明确职责组成名称含义X主版本号major存在向后不兼容的变更Y次版本号minor即feature release特性版本新增特性、既有功能改进Z补丁号patch针对 bugfix 与安全修复的增量在每次正式发布前Airflow 都会先放出一个候选版本Release CandidateRC通常还会伴随 alpha、beta 预发布版本。这些预发布版本的命名形式为X.Y.Z alpha/beta/rc N表示版本X.Y.Z的第 N 个 alpha / beta / 候选版本。当前仓库 airflow-core/src/airflow/init.py 中的__version__ 3.4.0即遵循这一格式不含预发布后缀。需要特别澄清的是Airflow 遵循 SemVer并不意味着 minor 或 patch 版本之间 100% 兼容。正如文档所引用的 Hynek Schlawack 的观点SemVer 本质上只是变更日志changelog的 TL;DR——对一个人而言的 bug可能是另一个人正依赖的特性。因此SemVer 是包作者意图的声明而非绝对兼容的保证。二、发布分支机制vX-Y-stable 与 cherry-pick 工作流在 git 中每个 minor 版本都有自己独立的分支命名为vX-Y-stable补丁bugfix/security版本均从该分支发布。关键规则包括禁止直接向发布分支提交Commit 和 PR 通常不应直接合入vX-Y-stable而应首先合入main分支再由发布经理release managercherry-pick 到对应发布分支。Milestone 关联通常会被纳入某个 bugfix/security 版本的变更会在 PR 上关联对应的 GitHub milestone。但文档明确说明这一过程目前是手工操作可能存在偏差。发布经理保留裁量权无论何种情况发布经理都保留将某个 PR 推迟到后续版本发布的权力。内容边界补丁版本不会加入任何新特性minor 版本当前的目标发布节奏约为23 个月一次。从仓库的发布实践看minor 发布流程还会在正式切分支前创建一个vX-Y-test测试分支用于累积待回移植的提交待 RC 投票通过后再合入vX-Y-stable。详见 dev/README_RELEASE_AIRFLOW.md。三、版本标签与签名机制每个 Airflow 发布版本都会在 git 中打上对应版本号的 tag并使用发布经理的密钥签名。tag 命名规则如下主 Airflow 发布版X.Y.Z不带前导vProviders 发布版providers-name/X.Y.Z签名机制贯穿整个发布与校验流程。发布前发布经理需要确认 GPG 签名密钥就绪gpg --list-secret-keys apache.org且密钥指纹已写入 Apache 的 KEYS 文件PMC 成员在验证 RC 时则通过gpg --verify校验每个.asc签名文件输出 Good signature from ... 即表示签名有效。四、三类版本详解Major / Feature / Patch文档以词汇表glossary形式给出了三类版本的准确定义这是理解 Airflow 版本策略的核心Major release主版本发布形式为X.0.0、X1.0.0表示一次向后不兼容的变更。没有固定的发布间隔也不遵循任何可预测的时间表。每次主版本发布时之前已弃用的特性将被移除。Feature releases特性版本发布形式为X.Y.0、X.Y1.0大约每两到三个月发布一次。包含新特性、既有功能的改进等。Patch releases补丁版本发布形式为X.Y.Z、X.Y.Z1按需发布——有问题被报告并修复时就发布。与对应的特性版本 100% 兼容。因此文档给出一个明确结论Should I upgrade to the latest patch release? 的答案永远是 yes应该升级。唯一例外当安全或数据丢失问题无法在不破坏向后兼容的前提下修复时可能打破 100% 兼容的承诺此时发布说明release notes会提供详细的升级指引。补丁版本绝不加入新特性。五、弃用策略Deprecation Policy一个主版本周期内的兼容承诺当既有特性被弃用或模块被重命名时Airflow 遵循如下规则现有代码继续工作但在执行时会发出DeprecationWarning或其子类。兼容期跨越整个当前主版本如果在 2.0.0 上能用那么在每一个2.Y.Z版本上都能用。文档给出的示例假设决定在 Airflow 2.2.4 开始弃用一个函数——Airflow 2.2 将包含该函数的向后兼容副本并抛出DeprecationWarningAirflow 2.3 继续工作并发出警告Airflow 3.0紧随 2.2 的下一个主版本将彻底移除该特性。唯一例外是标记为experimental实验性的特性它们可能在某个特性版本中遭遇破坏性变更或被彻底移除。这一策略在源码层面也有呼应Airflow 通过 Python 标准库的warnings模块配合DeprecationWarning实现弃用提示社区在贡献时也会通过tests/deprecations_ignore.yml见 tests/deprecations_ignore.yml统一管理被忽略的弃用警告清单确保弃用提示在测试环境中可控可见。六、实验性特性Experimental Features速度优先的免责条款某些新特性会被标记为实验性experimental其治理原则与正式特性截然不同没有弃用保证实验性特性不提供任何关于弃用的承诺。可随时破坏性变更可能在特性版本之间以破坏性方式更改甚至被彻底移除。尽力兼容但不承诺Airflow 团队始终尽力为实验性特性维持兼容性但不做任何承诺。文档明确指出这一退出通道get out的存在是为了让团队能够更快地构建新特性、更快地将它们交到用户手中而无需担心把特性打磨到完美。换言之实验性标签是快速迭代与用户先行体验之间的平衡点。七、从策略到实践RC 投票与可复现构建版本策略的落地依托于一套严谨的发布执行流程其完整操作手册位于 dev/README_RELEASE_AIRFLOW.md。以下几个实践环节与上述版本策略直接呼应7.1 RC 候选与投票机制每次正式发布前先产出 RC 候选且被投票的 RC 工件必须与最终发布工件内容完全一致仅允许重命名不允许任何修改。因此构建工件中的版本号不得包含rcN后缀这保证了投票通过的 RC 重命名后即可作为正式发布。投票通过标准至少 3 个 binding 的 1 票PMC 成员投票为 binding社区成员投票标注 non-binding投票时长通常不少于 72 小时。7.2 PMC 的五项法定校验PMC 成员需按 Apache Legal Release Policy 对 RC 进行校验包括可复现构建检查从相同源码能否构建出二进制一致的包SVN 检查工件是否正确放置在 dist 目录每个发布应包含 9 个文件-source.tar.gz/.tar.gz/-py3-none-any.whl各配.asc签名与.sha512校验和License 检查使用 Apache RAT 工具验证所有源码许可正确不应出现 Unknown 或 Unapproved 文件签名检查用 KEYS 文件中的公钥验证发布经理的 GPG 签名SHA512 校验和检查验证所有校验和与工件匹配。7.3 可复现构建的源码级实现Airflow 对可复现构建的支持可以从仓库中直接看到实现证据。根目录的 reproducible_build.yaml 记录了source-date-epoch与release-notes-hash两个关键值前者作为构建时的固定时间戳注入环境变量SOURCE_DATE_EPOCH从而消除包内时间戳差异。在 airflow-core/hatch_build.py 中自定义的 Hatch 构建插件会通过 git 仓库状态生成版本标识未打 tag 的预发布版本.dev0sha干净且基于 release tag 的版本.release:sha存在未提交改动追加.dirty后缀此外dev/breeze/src/airflow_breeze/utils/reproducible.py 中的repack_deterministically函数会在重新打包 tar.gz 时重置文件 owner/groupuid/gid 置 0、uname/gname 置 root、统一 mtime、在 C locale 下排序文件条目、清除 group 与 other 权限位并按固定模式处理符号链接——这些都是对齐 reproducible-builds.org 归档规范的典型做法。PMC 成员校验时用本地构建产物与 SVN 上发布的工件逐一diff输出为空即表示二进制一致。7.4 生产 Docker 镜像发布除 Python 包外每个版本还会同步发布生产级 Docker 镜像多平台构建支持 AMD64 与 ARM64。发布经理通过 Release PROD Images 工作流触发构建默认情况下新镜像会被打上latest标签对于旧分支上的紧急 bugfix 发布几乎不会发生则可以勾选跳过latest重打标签。镜像发布后还需对每个受支持的 Python 版本执行breeze prod-image verify验证。八、发布后的收尾工作正式发布后发布经理还需完成一系列收尾事项详见 dev/README_RELEASE_AIRFLOW.md在main分支更新版本号与 RELEASE_NOTES.rst、README、Dockerfile 等更新 Helm chart 中的默认 Airflow 版本chart/values.yaml、chart/values.schema.json、chart/Chart.yaml通过./dev/validate_version_added_fields_in_config.py脚本见 dev/validate_version_added_fields_in_config.py校验配置项version_added字段是否覆盖新版本依据 OpenAPI 规范变更情况决定是否跟进发布 Python / Go API 客户端。这些收尾动作确保新版本的版本号、默认值、配置文档与下游组件保持同步构成版本策略闭环的最后一环。总结Apache Airflow 的发布体系可以概括为SemVer 版本号表达意图稳定分支承载补丁RC 投票保证质量弃用策略管理兼容实验性特性换取迭代速度。理解这套策略你就能准确解读每个 Airflow 版本的发布含义判断升级风险并正确使用发布分支与 RC 机制参与社区协作。如果你正考虑为项目贡献修复或功能也可以据此决定修复应瞄准哪个分支、PR 应关联哪个 milestone以及哪些改动可能被发布经理推迟到后续版本。【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache Airflow 版本策略与发布流程全解析：SemVer、发布分支与弃用机制
Apache Airflow 版本策略与发布流程全解析SemVer、发布分支与弃用机制【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflowApache Airflow 从 2.0.0 与 Providers 1.0.0 起全面遵循语义化版本SemVer规范构建起一套覆盖版本号管理、发布分支、弃用策略与实验性特性治理的完整发布体系。本文以 airflow-core/docs/release-process.rst 为骨架结合仓库内的发布工具链Breeze、可复现构建配置与源码实现系统讲解 Airflow 的版本策略与发布流程。读完本文你将理解 Airflow 的版本号如何解读、补丁版本为何值得无条件升级、弃用特性如何分阶段移除以及实验性特性为何可以随时推翻重来。一、SemVer 版本策略X.Y.Z 三个数字各自代表什么Airflow 的版本号严格采用X.Y.Z三段式结构三段数字各有明确职责组成名称含义X主版本号major存在向后不兼容的变更Y次版本号minor即feature release特性版本新增特性、既有功能改进Z补丁号patch针对 bugfix 与安全修复的增量在每次正式发布前Airflow 都会先放出一个候选版本Release CandidateRC通常还会伴随 alpha、beta 预发布版本。这些预发布版本的命名形式为X.Y.Z alpha/beta/rc N表示版本X.Y.Z的第 N 个 alpha / beta / 候选版本。当前仓库 airflow-core/src/airflow/init.py 中的__version__ 3.4.0即遵循这一格式不含预发布后缀。需要特别澄清的是Airflow 遵循 SemVer并不意味着 minor 或 patch 版本之间 100% 兼容。正如文档所引用的 Hynek Schlawack 的观点SemVer 本质上只是变更日志changelog的 TL;DR——对一个人而言的 bug可能是另一个人正依赖的特性。因此SemVer 是包作者意图的声明而非绝对兼容的保证。二、发布分支机制vX-Y-stable 与 cherry-pick 工作流在 git 中每个 minor 版本都有自己独立的分支命名为vX-Y-stable补丁bugfix/security版本均从该分支发布。关键规则包括禁止直接向发布分支提交Commit 和 PR 通常不应直接合入vX-Y-stable而应首先合入main分支再由发布经理release managercherry-pick 到对应发布分支。Milestone 关联通常会被纳入某个 bugfix/security 版本的变更会在 PR 上关联对应的 GitHub milestone。但文档明确说明这一过程目前是手工操作可能存在偏差。发布经理保留裁量权无论何种情况发布经理都保留将某个 PR 推迟到后续版本发布的权力。内容边界补丁版本不会加入任何新特性minor 版本当前的目标发布节奏约为23 个月一次。从仓库的发布实践看minor 发布流程还会在正式切分支前创建一个vX-Y-test测试分支用于累积待回移植的提交待 RC 投票通过后再合入vX-Y-stable。详见 dev/README_RELEASE_AIRFLOW.md。三、版本标签与签名机制每个 Airflow 发布版本都会在 git 中打上对应版本号的 tag并使用发布经理的密钥签名。tag 命名规则如下主 Airflow 发布版X.Y.Z不带前导vProviders 发布版providers-name/X.Y.Z签名机制贯穿整个发布与校验流程。发布前发布经理需要确认 GPG 签名密钥就绪gpg --list-secret-keys apache.org且密钥指纹已写入 Apache 的 KEYS 文件PMC 成员在验证 RC 时则通过gpg --verify校验每个.asc签名文件输出 Good signature from ... 即表示签名有效。四、三类版本详解Major / Feature / Patch文档以词汇表glossary形式给出了三类版本的准确定义这是理解 Airflow 版本策略的核心Major release主版本发布形式为X.0.0、X1.0.0表示一次向后不兼容的变更。没有固定的发布间隔也不遵循任何可预测的时间表。每次主版本发布时之前已弃用的特性将被移除。Feature releases特性版本发布形式为X.Y.0、X.Y1.0大约每两到三个月发布一次。包含新特性、既有功能的改进等。Patch releases补丁版本发布形式为X.Y.Z、X.Y.Z1按需发布——有问题被报告并修复时就发布。与对应的特性版本 100% 兼容。因此文档给出一个明确结论Should I upgrade to the latest patch release? 的答案永远是 yes应该升级。唯一例外当安全或数据丢失问题无法在不破坏向后兼容的前提下修复时可能打破 100% 兼容的承诺此时发布说明release notes会提供详细的升级指引。补丁版本绝不加入新特性。五、弃用策略Deprecation Policy一个主版本周期内的兼容承诺当既有特性被弃用或模块被重命名时Airflow 遵循如下规则现有代码继续工作但在执行时会发出DeprecationWarning或其子类。兼容期跨越整个当前主版本如果在 2.0.0 上能用那么在每一个2.Y.Z版本上都能用。文档给出的示例假设决定在 Airflow 2.2.4 开始弃用一个函数——Airflow 2.2 将包含该函数的向后兼容副本并抛出DeprecationWarningAirflow 2.3 继续工作并发出警告Airflow 3.0紧随 2.2 的下一个主版本将彻底移除该特性。唯一例外是标记为experimental实验性的特性它们可能在某个特性版本中遭遇破坏性变更或被彻底移除。这一策略在源码层面也有呼应Airflow 通过 Python 标准库的warnings模块配合DeprecationWarning实现弃用提示社区在贡献时也会通过tests/deprecations_ignore.yml见 tests/deprecations_ignore.yml统一管理被忽略的弃用警告清单确保弃用提示在测试环境中可控可见。六、实验性特性Experimental Features速度优先的免责条款某些新特性会被标记为实验性experimental其治理原则与正式特性截然不同没有弃用保证实验性特性不提供任何关于弃用的承诺。可随时破坏性变更可能在特性版本之间以破坏性方式更改甚至被彻底移除。尽力兼容但不承诺Airflow 团队始终尽力为实验性特性维持兼容性但不做任何承诺。文档明确指出这一退出通道get out的存在是为了让团队能够更快地构建新特性、更快地将它们交到用户手中而无需担心把特性打磨到完美。换言之实验性标签是快速迭代与用户先行体验之间的平衡点。七、从策略到实践RC 投票与可复现构建版本策略的落地依托于一套严谨的发布执行流程其完整操作手册位于 dev/README_RELEASE_AIRFLOW.md。以下几个实践环节与上述版本策略直接呼应7.1 RC 候选与投票机制每次正式发布前先产出 RC 候选且被投票的 RC 工件必须与最终发布工件内容完全一致仅允许重命名不允许任何修改。因此构建工件中的版本号不得包含rcN后缀这保证了投票通过的 RC 重命名后即可作为正式发布。投票通过标准至少 3 个 binding 的 1 票PMC 成员投票为 binding社区成员投票标注 non-binding投票时长通常不少于 72 小时。7.2 PMC 的五项法定校验PMC 成员需按 Apache Legal Release Policy 对 RC 进行校验包括可复现构建检查从相同源码能否构建出二进制一致的包SVN 检查工件是否正确放置在 dist 目录每个发布应包含 9 个文件-source.tar.gz/.tar.gz/-py3-none-any.whl各配.asc签名与.sha512校验和License 检查使用 Apache RAT 工具验证所有源码许可正确不应出现 Unknown 或 Unapproved 文件签名检查用 KEYS 文件中的公钥验证发布经理的 GPG 签名SHA512 校验和检查验证所有校验和与工件匹配。7.3 可复现构建的源码级实现Airflow 对可复现构建的支持可以从仓库中直接看到实现证据。根目录的 reproducible_build.yaml 记录了source-date-epoch与release-notes-hash两个关键值前者作为构建时的固定时间戳注入环境变量SOURCE_DATE_EPOCH从而消除包内时间戳差异。在 airflow-core/hatch_build.py 中自定义的 Hatch 构建插件会通过 git 仓库状态生成版本标识未打 tag 的预发布版本.dev0sha干净且基于 release tag 的版本.release:sha存在未提交改动追加.dirty后缀此外dev/breeze/src/airflow_breeze/utils/reproducible.py 中的repack_deterministically函数会在重新打包 tar.gz 时重置文件 owner/groupuid/gid 置 0、uname/gname 置 root、统一 mtime、在 C locale 下排序文件条目、清除 group 与 other 权限位并按固定模式处理符号链接——这些都是对齐 reproducible-builds.org 归档规范的典型做法。PMC 成员校验时用本地构建产物与 SVN 上发布的工件逐一diff输出为空即表示二进制一致。7.4 生产 Docker 镜像发布除 Python 包外每个版本还会同步发布生产级 Docker 镜像多平台构建支持 AMD64 与 ARM64。发布经理通过 Release PROD Images 工作流触发构建默认情况下新镜像会被打上latest标签对于旧分支上的紧急 bugfix 发布几乎不会发生则可以勾选跳过latest重打标签。镜像发布后还需对每个受支持的 Python 版本执行breeze prod-image verify验证。八、发布后的收尾工作正式发布后发布经理还需完成一系列收尾事项详见 dev/README_RELEASE_AIRFLOW.md在main分支更新版本号与 RELEASE_NOTES.rst、README、Dockerfile 等更新 Helm chart 中的默认 Airflow 版本chart/values.yaml、chart/values.schema.json、chart/Chart.yaml通过./dev/validate_version_added_fields_in_config.py脚本见 dev/validate_version_added_fields_in_config.py校验配置项version_added字段是否覆盖新版本依据 OpenAPI 规范变更情况决定是否跟进发布 Python / Go API 客户端。这些收尾动作确保新版本的版本号、默认值、配置文档与下游组件保持同步构成版本策略闭环的最后一环。总结Apache Airflow 的发布体系可以概括为SemVer 版本号表达意图稳定分支承载补丁RC 投票保证质量弃用策略管理兼容实验性特性换取迭代速度。理解这套策略你就能准确解读每个 Airflow 版本的发布含义判断升级风险并正确使用发布分支与 RC 机制参与社区协作。如果你正考虑为项目贡献修复或功能也可以据此决定修复应瞄准哪个分支、PR 应关联哪个 milestone以及哪些改动可能被发布经理推迟到后续版本。【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考