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% 兼容，原因很简单：这不可能实现；对于一个人来说是 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% 兼容。因此，对于“我是否应该升级到最新的补丁版本？”这个问题，答案永远是“是”。
对于 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 添加标记为实验性的新功能。
实验性功能不提供任何弃用保证，在功能发布版本之间可能会以破坏性方式更改，甚至完全移除。
我们始终致力于即使对于实验性功能也保持兼容性，但对此不作任何承诺。通过这种“退出”方式，我们可以更快地构建新功能，并将它们交给用户，而无需担心使功能完美。