版本模型

回報問題 查看原始碼 。 夜間 7.2 7.1 7.0 6.5 6.4

如原始網誌的公告所述 post、Bazel 4.0 以上版本支援兩種測試群組：滾動式 以及長期支援 (LTS) 版本。本頁內容涵蓋 有關 Bazel 發布模型的資訊

支援矩陣

LTS 版本 支援階段 最新版本 停止支援
Bazel 8 滾動 查看滾動式版本頁面 不適用
Bazel 7 有效 7.2.1 2026 年 12 月
Bazel 6 維護 6.5.0 2025 年 12 月
Bazel 5 維護 5.4.1 2025 年 1 月
Bazel 4 已淘汰 4.2.4 2024 年 1 月

所有 Bazel LTS 版本都可找到此版本 頁面。

發布版本管理

Bazel 使用 major.minor.patch Semantic 版本管理架構。

  • 主要版本包含無法回溯相容的功能 每個主要 Bazel 版本都是 LTS 版本。
  • 次要版本包含回溯相容的錯誤修正和功能 從主要分支版本向後移植。
  • 修補程式版本包含重大錯誤修正。

此外，發行前版本後面會加上連字號和 將日期後置字串加在下一個主要版本號碼

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

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

支援階段

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

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

發布頻率

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

滾動式版本

  • 推出作業採用與 Google Blaze 版本協調並發布 每兩週從 HEAD 起它是下一個 Bazel LTS 的預先發布版 版本。
  • 滾動式版本可能會發布不相容的變更。不相容的標記為 建議用於重大破壞性變更，以及推出不相容的變更 應用程式應遵循回溯相容性 政策。

LTS 版本

  • 主要版本：新的 LTS 版本預計將從 HEAD 版本中切斷 每 12 個月。新的 LTS 發布後，就會立即進入運作中狀態 ，且先前的 LTS 版本會進入「維護」階段。
  • 次要版本：雖然有效 LTS 測試群組會推出新的小版本 每 2 個月發布一次
  • 修補程式版本：適用於運作中及 LTS 版本的最新修補程式版本 維護階段預計依重大錯誤釋出 找出程式碼中的安全漏洞和錯誤 並提供修正建議
  • Bazel LTS 版本會在進入 維護階段達 2 年。

如需預定發布的版本，請參閱版本資訊 問題 前往 GitHub。

發布程序與政策規定

對滾動式的版本來說，這項程序相當簡單：大約每兩週一次， 新版本的建構方式，與 Google 內部使用的基準一致 Blaze 版本。由於發布時間縮短，我們不會將任何變更向後移植 。

針對 LTS 版本，程序和政策如下：

  1. 決定版本的基準修訂版本。
    • 針對新的主要 LTS 版本，基準修訂版本是主要 LTS 的
    • 如果是次要或修補程式版本，基準修訂版本是 上一個 LTS 版本的最新版本。
  2. 從基準的 release-<version> 名稱中建立版本分支版本 修訂版本。
  3. 透過 PR 將變更向後移植到發布分支版本。
    • 社群成員可藉由回覆 「@bazel-io flag」，在相關 GitHub 問題或 PR 上標示為可能 Bazel 團隊會將這些因素分類，並決定是否 反向移植修訂版本。
    • 只有主要分支版本的回溯相容修訂版本才能向後移植， 接受額外的小幅變更來解決合併衝突。

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

    • Bazel 維護人員可以要求選擇特定修訂版本 移至發布分支版本這項程序會先透過 在 GitHub 上挑選 cherry-ick 要求做法如下。

      1. 開啟選擇 cherry-ick 要求
      2. 填寫要求詳細資料
        • 標題：為要求提供簡要的描述性標題。
        • 修訂版本 ID：輸入您要執行的修訂版本 ID 做出選擇如有多個修訂版本，請將 以半形逗號隔開
        • 類別：指定要求的類別。
        • 審查者：如有多位審查者，請分別建立 GitHub
      3. 設定里程碑
        • 找出「里程碑」然後按一下設定
        • 選取適當的 X.Y.Z 解除攔截器。這個動作 會觸發 Cherry 挑選機器人來處理你的要求 「release-X.Y.Z」
      4. 提交問題
        • 填妥所有詳細資料並完成重要步驟後， 提交問題。

    • 櫻桃機器人會處理要求，並通知 是否有可採摘櫻桃的修訂版本。如果 修訂版本可挑選 選擇合併修訂版本時合併衝突，然後 機器人會建立新的提取要求提取時 Bazel 團隊的成員就會核准要求 系統會挑選特定修訂版本並合併至分支版本。 如要查看已完成的櫻花要求的影像範例 請參考這個 範例 ，直接在 Google Cloud 控制台實際操作。

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

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

  6. 如果所有已知項目都已知，則從發布分支版本建立新的候選版本 發布攔截器已獲得解決

    • 候選版公布日期： bazel-discuss Bazel 團隊會監控候選人的社群錯誤報告。
    • 如果發現新的發布阻礙，請返回最後一個步驟， 解決所有問題後，建立新的候選版。
    • 在此之後，就無法在版本分支版本中新增功能 建立第一個候選版櫻桃小禮物 僅修正這些錯誤。如果需要選擇 Cherry 部分中，要求者必須回答 問：為什麼這項變更很重要？ 該怎麼辦？這項異動帶來的影響 會發生迴歸？

  7. 如果不再發布，請將候選版推送為正式版 發現障礙物

    • 如果是修補程式版本，請至少在兩個工作天後推送該版本 最後一個候選版本已過舊
    • 如果是主要版本和次要版本，請在兩個工作天後推送發布版本 最後一版候選版已過，但時間不會超過一週 第一版候選版已結束。
    • 這個版本只會推送到隔天營業的那一天 當天。
    • 版本宣布日期： bazel-discuss Bazel 團隊會監控並解決新舊版本的社群錯誤報告 版本。

回報迴歸問題

如果使用者在新的 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 環境變數 以便重設建構狀態 重現問題。詳情請參閱 Bazelisk 的說明文件 Bise 功能。

請記得將 Bazelisk 升級至最新版本，以便使用 Bisect 而不是每個特徵的分數

規則相容性

如果您是規則作者，且想與不同的 Bazel 版本，請查看規則 相容性網頁。