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

自 Airflow 2.0.0 和 provider 包 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 通常不应直接进入这些分支，而应以主分支为目标，然后由发布管理者将它们 cherry-pick 到这些发布分支。作为一般经验法则，将包含在错误修复/安全版本中的更改将与 PR 中对应的 github 里程碑相关联，但这目前是一个手动过程，可能会出现偏差。在所有情况下，如果发布管理者认为谨慎，他们保留将 PR 推迟到后续版本的权利。此外，补丁版本中不会添加任何新功能，并且次版本目前的发布目标大约为每 2-3 个月一次。

每个 Airflow 版本也将在 git 中有一个标签，指示其版本号，并使用发布管理者的密钥签名。主 Airflow 版本的标签格式为 X.Y.Z（没有前导 v），而 provider 包的标签格式为 providers-<name>/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 中，并将其标记为实验性。

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

我们始终致力于保持兼容性，即使对于实验性功能也是如此，但不做任何承诺。通过这种“摆脱困境”的方式，我们可以更快地构建新功能，并将它们交到用户手中，而不必担心使功能完美。