版本模型

回報問題 查看來源 Nightly

如原始網誌文章所述，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 月

您可以在 GitHub 的版本頁面中找到所有 Bazel LTS 版本。

發布版本管理

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

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

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

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

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

支援階段

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

  • 滾動：這個主要版本仍在預先發布階段，Bazel 團隊會發布 HEAD 的滾動式版本。
  • 有效：這個主要版本是目前使用中的 LTS 版本。Bazel 團隊會將重要功能和錯誤修正向後移植到其子版本。
  • 維護：這個主要版本是維護模式下的舊版 LTS 版本。Bazel 團隊承諾僅會將重大錯誤修正程式向後移植到此 LTS 版本。
  • 已淘汰：Bazel 團隊不再支援這個主要版本，因此所有使用者應改用較新的 Bazel LTS 版本。

發布頻率

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

滾動式版本

  • 滾動式版本和 Google Blaze 版本協調發布，大約每兩週就會從 HEAD 發布。而是用來預覽下一個 Bazel LTS 版本。
  • 滾動式版本可能會發布不相容的變更。針對重大破壞性變更，建議使用不相容的標記，因此推出不相容的變更應遵循我們的回溯相容性政策。

LTS 版本

  • 主要版本：新的 LTS 版本預計每隔 12 個月就會從 HEAD 版本中切斷。新的 LTS 發布後，會立即進入「執行中」階段，而先前的 LTS 版本會進入「維護」階段。
  • 次要版本：有效 LTS 測試群組的新次要版本預計每 2 個月發布一次。
  • 修補程式版本：針對「執行中」和「維護」階段中的 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 上建立 Cherry 選擇要求時啟動。做法如下。

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

    • Cherry 挑選的機器人會處理要求，並通知修訂版本是否符合挑選櫻桃的資格條件。如果可挑選的修訂版本，這表示在挑選 Cherry 的修訂版本時不會有合併衝突，機器人就會建立新的提取要求。當 Bazel 團隊成員核准提取要求後，系統就會挑選該修訂版本，並將其合併至發布分支版本。如需完成 Cherry 選擇要求的視覺範例，請參閱這個範例。

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

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

  6. 解析所有已知的版本攔截器後，從版本分支版本建立新的候選版。

    • 候選版會在 bazel-discuss 公告中宣布，Bazel 團隊會監控候選人的社群錯誤報告。
    • 如果發現新的發布阻礙，請返回最後一個步驟，並在解決所有問題後建立新的候選版。
    • 建立第一個候選版本後，就無法在發布分支版本中新增功能；cherry-picks 僅限於重要修正項目。如果需要挑選櫻桃，要求者必須回答下列問題：為什麼這項變更很重要？它能提供哪些好處？這項變更造成迴歸的可能性為何？

  7. 如果未發現其他發布瓶頸，請將候選版推送為正式版

    • 如果是修補程式版本，請至少在候選版脫離前兩個工作天推送該版本。
    • 如果是主要版本和次要版本，請在最後一個候選版本淘汰後兩個工作天內推送版本，但不要在第一個候選版本推出至少一週後推出新版本。
    • 版本只會推送日期到下一個工作天為工作天。
    • 版本會在 bazel-discuss 公告中宣布，Bazel 團隊會監控及處理新版本的社群錯誤報告。

回報迴歸問題

如果使用者在新的 Bazel 版本中發現迴歸，或者在 HEAD 版本發布候選，或甚至在 Bazel 處發布 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 智慧功能說明文件。

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

規則相容性

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