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，錯誤修正/安全性發布將由此分支發布。Commit 和 PR 通常不應直接進入這些分支，而應以 main 分支為目標，然後由發布管理員 cherry-pick 到這些發布分支。一般來說，將包含在錯誤修正/安全性發布中的變更將與 PR 中對應的 github 里程碑相關聯，但目前這是一個手動過程，可能會出現偏差。在所有情況下，發布管理員保留將 PR 推遲到稍後發布的權利，如果他們認為這是明智的。此外，修補程式發布中不會新增任何新功能，而次要版本的目標目前約為 2-3 個月的節奏。

每個 Airflow 發布版本也會在 git 中有一個標籤，指示其版本號碼，並使用發布管理員的金鑰簽署。主要 Airflow 發布版本的標籤格式為 X.Y.Z (沒有前導 v)，而供應商套件的標籤格式為 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 中，並標記為實驗性。

實驗性功能對於棄用沒有任何保證，並且可能在功能發布版本之間以破壞性的方式進行變更，甚至完全移除。

我們始終致力於保持相容性，即使是實驗性功能，但不做任何承諾。透過擁有這個「退出」機制，我們可以更快地建構新功能，並將它們交到使用者手中，而無需擔心使功能完美。