版本模型

每日 · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

如原始網誌文章所述，Bazel 4.0 以上版本支援兩種發布群組：滾動式發布和長期支援 (LTS) 發布。本頁面提供 Bazel 發布模型的最新資訊。

支援矩陣

LTS 版本 支援階段 最新版本 停止支援
Bazel 10 滾動 查看滾動式發布頁面 不適用
Bazel 9 有效 9.3.1 2028 年 12 月
Bazel 8 維護 8.8.2 2027 年 12 月
Bazel 7 維護 7.7.2 2026 年 12 月
Bazel 6 已淘汰 6.6.0 2025 年 12 月
Bazel 5 已淘汰 5.4.1 2025 年 1 月
Bazel 4 已淘汰 4.2.4 2024 年 1 月

所有 Bazel LTS 版本都可在 GitHub 的版本頁面找到。GitHub 上的「最新」徽章一律指向最高語意版本，即使最近發布了舊版本的維護修補程式也一樣。

發布版本管理

Bazel 採用major.minor.patch 語意化版本配置。

  • 「主要版本」包含與先前版本不回溯相容的功能。每個 Bazel 主要版本都是 LTS 版本。
  • 次要版本包含回溯相容的修正錯誤，以及從主要分支版本向後移植的功能。
  • 修補程式版本包含重大錯誤修正。

此外，預先發布版會在下一個主要版本號碼後方加上連字號和日期後置字串。

舉例來說，每種類型的新版本會產生以下版本號碼：

  • 主要：6.0.0
  • 次要：6.1.0
  • 修補程式：6.1.2
  • 預先發布版：7.0.0-pre.20230502.1

支援階段

每個 Bazel 主要版本都有四個支援階段：

  • Rolling：這個主要版本仍在預先發布版階段，Bazel 團隊會從 HEAD 發布滾動式版本。
  • 有效：這個主要版本是目前有效的 LTS 版本。Bazel 團隊會將重要功能和錯誤修正向後移植到次要版本。
  • 維護：這個主要版本是處於維護模式的舊版 LTS。Bazel 團隊僅承諾將安全性問題和 OS 相容性問題的重大錯誤修正，向後移植到這個 LTS 版本。
  • 已淘汰：Bazel 團隊不再支援這個主要版本，所有使用者都應遷移至較新的 Bazel LTS 版本。

發布頻率

Bazel 會定期發布兩個發布群組的版本。

滾動式版本

  • 滾動式版本會與 Google Blaze 版本協調，並大約每兩週從 HEAD 發布一次。這是下一個 Bazel LTS 版本的預先發布版。
  • 滾動式版本可能會推出不相容的變更。建議在重大破壞性變更時使用不相容標記，推出不相容變更時，應遵循回溯相容性政策。

LTS 版本

  • 主要版本：預計大約每 12 個月會從 HEAD 推出新的 LTS 版本。新的 LTS 版本推出後，會立即進入「有效」階段，而先前的 LTS 版本則會進入「維護」階段。
  • 子版本：Active LTS 測試群組預計每 2 個月發布一次新的子版本。
  • 修補程式版本：處於「Active」和「Maintenance」階段的 LTS 版本，會視需要發布新的修補程式版本，修正重大錯誤。
  • Bazel LTS 版本在維護階段 2 年後，就會進入「已淘汰」階段。

如要瞭解預定發布的版本，請查看 GitHub 上的版本問題。

發布程序和政策

滾動式發布版本的流程很簡單：大約每兩週會建立一個新版本，與 Google 內部 Blaze 版本的基準相同。由於發布時間表緊湊，我們不會將任何變更向後移植到滾動式版本。

LTS 版本遵循下列程序和政策：

  1. 決定版本的基準修訂版本。
    • 如果是新的主要 LTS 版本，基準修訂版本就是主分支版本的 HEAD。
    • 如果是子版本或修補程式版本，基準修訂版本則是相同 LTS 版本目前最新版本的 HEAD。
  2. 從基準修訂版本建立名為 release-<version> 的發布分支版本。
  3. 透過 PR 將變更向後移植至發布分支版本。
    • 社群成員可以建議向後移植特定修訂版本，方法是在相關 GitHub 問題或 PR 上回覆「@bazel-io flag」，將其標示為潛在的發布阻礙，Bazel 團隊會進行分類，並決定是否向後移植修訂版本。
    • 只有主分支版本上回溯相容的修訂版本才能向後移植，但可以接受其他次要變更來解決合併衝突。

  4. 使用 Bazel 維護人員的 Cherry-Pick 要求問題，向後移植變更。

    • Bazel 維護者可以要求將特定修訂版本挑選至發布分支版本。這項程序會先在 GitHub 上建立挑選要求。做法如下。

      1. 開啟挑選要求
      2. 填寫要求詳細資料
        • 標題：提供簡潔、具描述性的要求標題。
        • 修訂版本 ID：輸入要挑選的修訂版本 ID。如果有多個修訂版本，請以半形逗號分隔。
        • 類別：指定要求的類別。
        • 審查者：如有多位審查者，請以半形逗號分隔他們的 GitHub ID。
      3. 設定里程碑
        • 找到「里程碑」部分，然後按一下設定。
        • 選取適當的 X.Y.Z 版本阻礙因素。這項操作會觸發挑選機器人，處理「release-X.Y.Z」分支版本的要求。
      4. 提交問題
        • 填妥所有詳細資料並設定里程碑後，即可提交問題。

    • 挑選機器人會處理要求，並在修訂版本符合挑選條件時通知您。如果修訂版本可挑選，也就是挑選修訂版本時沒有合併衝突，機器人就會建立新的提取要求。提取要求經 Bazel 團隊成員核准後，系統會挑選修訂版本並合併至發布分支版本。如需完成挑選要求的視覺範例，請參閱這個範例。

  5. 找出版本阻礙，並修正版本分支版本中發現的問題。

    • 在 Bazel CI 上，發布分支版本會使用postsubmit和下游測試管道中的相同測試套件進行測試。Bazel 團隊會監控發布分支版本的測試結果，並修正發現的任何迴歸問題。

  6. 解決所有已知的版本阻礙因素後，請從版本分支建立新的候選版本。

    • 候選版會在 bazel-discuss 上公布，Bazel 團隊會監控社群對候選版的錯誤報告。
    • 如果發現新的版本阻礙，請返回上一個步驟，並在解決所有問題後建立新的候選版本。
    • 建立第一個候選版本後，不得在發布分支版本中新增功能，且僅限挑選重要修正項目。如果需要挑選，要求者必須回答下列問題：這項變更為何重要？能帶來什麼好處？這項變更造成迴歸的可能性有多高？

  7. 如果沒有發現其他發布阻礙，請將候選版本推送為正式版本

    • 如果是修補程式版本，請在最後一個候選版本推出後，至少等待兩個工作天再推送版本。
    • 如果是主要和次要版本，請在最後一個候選版本推出後兩個工作天推送版本，但不得早於第一個候選版本推出後一週。
    • 版本只會在隔天是工作天的日子推送。
    • 版本發布後，Bazel 團隊會在 bazel-discuss 上公告，並監控及處理社群對新版本的錯誤報告。

回報迴歸

如果使用者在新的 Bazel 版本、候選版本，甚至是 HEAD 的 Bazel 中發現迴歸，請在 GitHub 上回報錯誤。您可以使用 Bazelisk 找出有問題的修訂版本，並將這項資訊加入錯誤報告。

舉例來說，如果建構作業在 Bazel 6.1.0 成功，但在 6.2.0 的第二個候選版失敗，您可以透過以下方式進行二分法

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

您可以設定 BAZELISK_SHUTDOWN 或 BAZELISK_CLEAN 環境變數，執行對應的 bazel 指令，在需要重現問題時重設建構狀態。詳情請參閱 Bazelisk bisect 功能的說明文件。

請記得將 Bazelisk 升級至最新版本，才能使用 bisect 功能。

規則相容性

如果您是規則作者，且想維持與不同 Bazel 版本的相容性，請參閱「規則相容性」頁面。