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

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

每个Airflow版本在git中也会有一个标签表示其版本号，由发布管理员的密钥签名。主Airflow版本的标签格式为X.Y.Z（不带前导v），而provider包的标签格式为providers-/X.Y.Z。

尽管Airflow遵循SemVer版本规范，但这并不保证次要版本或补丁版本之间100%兼容，原因很简单：对某些人来说是缺陷的问题，可能正是其他人依赖的功能特性。

了解维护者的意图很有价值——尤其是当出现问题的时候。因为这就是SemVer的全部含义：变更日志的简要说明。

——海尼克·施拉瓦克 https://hynek.me/articles/semver-will-not-save-you/

这就是SemVer的全部含义——它表达了我们作为包作者的意图，以及我们目标的明确声明。

Major release¶

主要版本（X.0.0、X+1.0.0等）表示存在向后不兼容的变更。

这些发布没有固定的时间间隔或可预测的时间表。

每次发布新主版本时，之前弃用的功能将被移除。

Feature releases¶

功能版本（X.Y.0、X.Y+1.0等）大约每两到三个月发布一次——详情请参阅发布流程。这些版本将包含新功能、现有功能的改进等内容。

Patch releases¶

补丁版本（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 会不时添加一些被标记为实验性的新功能。

实验性功能不提供任何关于废弃的保证，并且可能在功能版本之间以破坏性方式更改，甚至完全移除。

我们始终致力于保持兼容性，即使是实验性功能也不例外，但无法做出承诺。通过这种"退出机制"，我们可以更快地开发新功能并将其交到用户手中，而无需担心功能的完美性。