Airflow 的发布流程和版本政策
自 Airflow 2.0.0 和 providers 1.0.0 起，我们旨在遵循 SemVer，意味着发布编号如下：
版本号的形式为 X.Y.Z。
X 是主版本号。
Y 是次版本号，也称为 功能发布 版本号。
Z 是补丁号，用于错误修复和安全发布。每次新版本发布前，我们会提供候选版本，通常还有 alpha 或 beta 版。这些形式为 X.Y.Z alpha/beta/rc N，表示 X.Y.Z 版本的第 N 个 alpha / beta / 候选发布。
在 git 中，每个次版本都有自己的分支，称为 vX-Y-stable，从该分支发布错误修复/安全补丁。提交和 PR 通常不直接推送到这些分支，而是先针对 main 分支，然后由发布管理员挑选（cherry‑pick）到相应的发布分支。一般经验是，纳入错误修复/安全补丁的更改会在 PR 中关联对应的 GitHub milestone，但这目前是手动过程，可能出现偏差。在任何情况下，发布管理员保留将 PR 推迟至后续发布的权利，如果他们认为有必要。此外，补丁发布不会加入新特性，次版本发布目前的周期大约为 2‑3 个月。
每个 Airflow 发布也会在 git 中打上标签，指示其版本号，并使用发布管理员的密钥签名。主 Airflow 发布的标签形式为 X.Y.Z（不带前导 v），而 providers 的标签形式为 providers-<name>/X.Y.Z。
虽然 Airflow 遵循 SemVer，但这并不保证次版本或补丁版本之间 100% 的兼容性，因为这根本不可能：对某个人是 bug 的东西，可能是另一位用户依赖的功能。
了解维护者的 意图 可能非常有价值——尤其是在 出现故障 时。因为这正是 SemVer 所代表的：变更日志的 TL;DR。
—Hynek Schlawack https://hynek.me/articles/semver-will-not-save-you/
这就是 SemVer 的全部——它是我们作为包作者的意图声明，也是我们目标的明确声明。
- 主要发布
主要发布（X.0.0、X+1.0.0 等）表示向后不兼容的更改。
这些发布没有固定的间隔或可预测的时间表。
每次发布新主版本时，之前已废弃的特性都会被移除。
- 功能发布
功能发布（X.Y.0、X.Y+1.0 等）大约每两到三个月发生一次——具体请参见发布流程。这类发布会包含新特性、对已有特性的改进等内容。
- 补丁发布
补丁发布（X.Y.Z、X.Y.Z+1 等）会根据需要在报告并修复问题后进行。
这些发布将与对应的功能发布 100% 兼容。因此对 “是否应该升级到最新的补丁发布？” 的答案永远是 “是”。
唯一例外是当安全或数据丢失问题无法在不破坏向后兼容性的情况下修复时。如果出现这种情况，发行说明会提供详细的升级指引。补丁发布不会加入新特性
废弃政策
不时会有现有特性被废弃，或模块被重命名。
发生此情况时，现有代码仍可运行，但在执行时会触发 DeprecationWarning（或其子类）。该代码在当前主版本的其余时间内仍然可用——如果它在 2.0.0 上可用，则在所有 2.Y.Z 发行版上都可用。
例如，如果我们决定在 Airflow 2.2.4 开始废弃某个函数
Airflow 2.2 将包含该函数的向后兼容副本，并在调用时抛出 DeprecationWarning
Airflow 2.3 将继续工作并发出警告
Airflow 3.0（紧随 2.2 的主版本）将彻底移除该特性
此废弃政策的例外是标记为 “实验” 的任何特性，它们 可能 在功能发布之间出现破坏性更改或被完全移除。
实验特性
不时会向 Airflow 添加新特性，并将其标记为实验。
实验特性不提供任何废弃方面的保证，并且在功能发布之间 可能 以破坏性的方式更改，甚至被全部移除。
我们始终努力在实验特性上保持兼容性，但不作任何承诺。设立这种 “退出” 机制，使我们能够更快地构建新特性并交付给用户，而无需担心把特性做到完美。