版本政策

從 Spark 1.0.0 開始，Spark 專案將遵循語意版本準則，並做一些微小的調整。這些微小的差異是考量到 Spark 作為多模組專案的特性。

Spark 版本

每個 Spark 版本將會採用下列版本編號：[主要版本].[功能].[維護]

主要版本：所有具有相同主要版本號碼的版本都將具有 API 相容性。主要版本號碼會在很長一段時間內保持穩定。例如，1.X.Y 可能會持續 1 年或更久。
功能：功能版本通常會包含新功能、改善和錯誤修正。每個功能版本都會有一個合併視窗，可以在其中合併新的修補程式，一個只能合併修正的 QA 視窗，然後是一個對候選版本進行投票的最後時段。這些視窗會在先前的功能版本發布後立即公告，以給予人們充足的時間，而且隨著時間的推移，我們可能會讓整個發布流程更為規律（類似於 Ubuntu）。
維護：維護版本會更頻繁地發布，並取決於引進的特定修補程式（例如錯誤修正）及其緊急性。一般來說，這些版本旨在修補錯誤。但是，較高層級的函式庫可能會引進小型功能，例如新的演算法，前提是它們完全是新增的，而且與現有的程式碼路徑隔離。Spark 核心可能不會引進任何功能。

Alpha 元件

當新的元件新增到 Spark 時，它們最初可能會標記為「alpha」。Alpha 元件不必遵守上述準則，但是，在可能的最大範圍內，它們應該盡量遵守。一旦它們被標記為「穩定」，就必須遵循這些準則。

API 相容性

API 是 Spark 中公開的任何公共類別或介面，未標記為「開發人員 API」或「實驗性質」。版本 A 與版本 B 相容，如果針對版本 A 編譯的程式碼可以順利編譯為 B。目前，並不能保證針對版本 A 連結的已編譯應用程式可以在不重新編譯的情況下順利連結到版本 B。連結層級相容性是我們將嘗試在未來版本中保證的。

不過請注意，即使對於「開發人員 API」和「實驗性」功能，我們仍致力於維持最大的相容性。如果計畫稍後變更 API，則不應將程式碼合併到專案中標示為「實驗性」，因為使用者預期所有可用的 API 都能提供最大的相容性。

中斷 API 時的考量

Spark 專案致力於避免中斷 API 或在主要版本中無聲變更行為。雖然這並非總是可行，但在選擇中斷 API 之前，應考量以下因素的平衡。

中斷 API 的成本

中斷 API 幾乎總是會對 Spark 使用者造成非同小可的成本。中斷的 API 表示 Spark 程式在升級之前需要重新撰寫。不過，在考量成本時有幾個考量因素

使用率 - 在許多不同地方積極使用的 API，中斷的成本總是很高。雖然很難確定使用率，但我們有許多方法可以估計
- API 已在 Spark 中存在多久？
- 即使對於基本程式，API 是否也很常見？
- 我們在 JIRA 或郵件清單中看到最近的問題的頻率為何？
- 它在 StackOverflow 或部落格中出現的頻率為何？
中斷後的行為 - 今天運作的程式，在中斷後將如何運作？以下列出的大致順序為嚴重性遞增
- 是否會有編譯器或連結器錯誤？
- 是否會有執行時期例外狀況？
- 是否會在完成大量處理後發生例外狀況？
- 我們是否會無聲傳回不同的答案？（很難偵錯，甚至可能不會注意到！）

維護 API 的成本

當然，以上並不表示我們永遠不會中斷任何 API。我們還必須考量專案和使用者保留相關 API 的成本。

專案成本 - 我們擁有的每個 API 都需要測試，並且需要在專案的其他部分變更時持續運作。當外部依賴項變更（JVM、Scala 等）時，這些成本會大幅增加。在某些情況下，雖然在技術上並非完全不可行，但維護特定 API 的成本可能會過高。
使用者成本 - API 也會對學習 Spark 或嘗試了解 Spark 程式的人造成認知成本。當有問題的 API 具有令人困惑或未定義的語意時，此成本會變得更高。

中斷 API 的替代方案

在「不良 API」存在，但移除成本也很高的情況下，應考慮不傷害現有使用者，但能解決部分維護成本的替代方案。

避免不良 API - 雖然這有點明顯，但這是一個重點。任何時候我們向 Spark 新增新的介面時，我們都應該考慮我們可能永遠被這個 API 卡住。深入思考新的 API 如何與現有的 API 相關，以及你預期它們如何隨著時間演進。
棄用警告 - 所有棄用警告都應指向明確的替代方案，且絕不應僅表示 API 已棄用。
更新的文件 - 文件應指向執行特定任務的「最佳」建議方式。在我們維護舊版文件的情況下，我們應明確指向更新的 API，並向使用者建議「正確」的方式。
社群工作 - 許多人透過閱讀部落格和其他網站（例如 StackOverflow）來學習 Spark。然而，其中許多資源已過時。更新它們，以降低最終移除已棄用 API 的成本。

發布節奏

分支會在每年 1 月和 7 月切換，因此功能（「次要」）版本通常約每 6 個月發布一次。因此，Spark 2.3.0 通常會在 2.2.0 發布後約 6 個月發布。維護版本會在功能版本之間視需要發布。主要版本並非根據固定時間表發布。

Spark 3.5 發布時程

日期	活動
2023 年 7 月 16 日	程式碼凍結。切換發布分支。
2023 年 7 月底	QA 時期。專注於錯誤修正、測試、穩定性和文件。通常不會合併新的功能。
2023 年 8 月	候選版本 (RC)、投票等，直到最終版本通過

維護版本和 EOL

功能版本分支通常會在 18 個月內維護錯誤修正版本。例如，2.3.x 分支在 2019 年 9 月（2.3.0 於 2018 年 2 月發布後 18 個月）被視為不再維護。在該時間點之後，不應再期待任何 2.3.x 版本，即使是錯誤修正版本。

主要版本中的最後一個次要版本通常會作為「LTS」版本維護更長的時間。例如，2.4.0 於 2018 年 11 月 2 日發布，並在 2021 年 5 月發布 2.4.8 之前維護了 31 個月。2.4.8 是最後一個版本，不應再期待任何 2.4.x 版本，即使是錯誤修正版本。