Airflow 的发布流程和版本策略¶

自 Airflow 2.0.0 和提供程序包 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 中相应的 GitHub 里程碑相关联，但这目前是一个手动过程，可能会出现偏差。在任何情况下，如果发布管理员认为谨慎起见，他们保留将 PR 推迟到以后版本的权利。此外，补丁版本中不会添加任何新功能，次版本目前的目标发布周期约为 2-3 个月。

每个 Airflow 版本在 git 中也会有一个标签，指示其版本号，并使用发布管理员的密钥签名。主 Airflow 版本的标签格式为 X.Y.Z（没有前导 v），提供程序包的标签格式为 providers-<名称>/X.Y.Z。

尽管 Airflow 遵循 SemVer，但这并不能保证次版本或补丁版本之间 100% 兼容，因为这是不可能的：对一个人来说是错误的东西对另一个人来说可能是依赖的功能。

了解维护者的*意图*可能很有价值，尤其是在出现问题*时*。因为 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% 兼容。所以“我应该升级到最新的补丁版本吗？”的答案永远是“是”。

以上关于 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 中会不时添加标记为实验性的新功能。

实验性功能不保证弃用，并且*可能*在功能版本之间以破坏性方式更改，甚至完全删除。

我们始终致力于保持兼容性，即使是实验性功能，但我们不作任何承诺。通过拥有这种“退出”机制，我们可以更快地构建新功能并将其交到用户手中，而不必担心使功能完美无缺。