版本模型

回報問題 查看原始碼

原始網誌文章所述,Bazel 4.0 及以上版本支援兩種測試群組:滾動式版本和長期支援 (LTS) 版本。本頁面說明 Bazel 發布模型的最新資訊。

支援矩陣

LTS 版本 支援階段 最新版本 支援終止
Bazel 8 累計 查看「滾動式版本」頁面 不適用
Bazel 7 運作中 7.1.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 版本都可以在 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 版本發布後,會立即進入 Active 階段,而先前的 LTS 版本則會進入維護階段。
  • 次要版本:Active LTS 測試群組新的小版本預計會每 2 個月推出一次。
  • 修補程式版本:對於「使用中」和「維護」階段的 LTS 版本,我們預計會隨需求推出新的修補程式版本,進行重大錯誤修正。
  • Bazel LTS 版本進入「維護」階段 2 年後,就會進入「已淘汰」階段。

如要瞭解預定版本,請查看 GitHub 上的版本問題

發布程序與政策

滾動式版本的程序相當簡單:大約每兩週就會建立新版本,與 Google 內部 Blaze 版本保持一致。由於發布時程快速,我們不會向後移植任何滾動式版本變更。

如為 LTS 版本,請遵循下列程序和政策:

  1. 決定版本的基準修訂版本。
    • 對於新的主要 LTS 版本,基準修訂版本是主要分支版本的 HEAD。
    • 如果是次要版本或修補程式版本,基準修訂版本是相同 LTS 版本目前最新版本的標頭。
  2. 從基準修訂版本的 release-<version> 名稱中建立發布分支版本。
  3. 透過 PR 將變更向後移植至發布分支版本。
    • 社群可以建議要向後移植某些修訂版本,方法是針對相關 GitHub 問題或 PR 回覆「@bazel-io flag」,將這些項目標示為潛在發布攔截器,Bazel 團隊會將這些修訂版本分類,並決定是否要將修訂版本向後移植。
    • 只有主要分支版本上的回溯相容修訂版本可以向後移植,而需要進行其他小幅變更來解決合併衝突。
  4. 使用 Cherry-Pick 要求問題向 Bazel 維護人員向後移植變更。

    • Bazel 維護人員可以要求將特定修訂版本匯出至發布分支版本。這項程序的第一步是在 GitHub 建立 cherry 挑選要求。做法如下。

      1. 開啟cherry-Pick 要求
      2. 填寫要求詳細資料
        • 標題:為要求提供簡明扼要的標題。
        • 修訂版本 ID:輸入要挑選的修訂版本 ID。如果您有多個修訂版本,請以半形逗號分隔。
        • 類別:指定要求的類別。
        • 審查者:如果有多個審查人員,請以半形逗號分隔他們的 GitHub ID。
      3. 設定里程碑
        • 找到「里程碑」部分並按一下設定。
        • 選取適當的 X.Y.Z 發布攔截器。這個動作會觸發 cherry 挑選的機器人,以處理您對「release-X.Y.Z」分支版本的要求。
      4. 提交問題
        • 填妥所有詳細資料並設定 miestone 後,請提交問題。
    • cherry 挑選的機器人會處理要求,並通知修訂版本是否有資格進行 Cherry 挑選。如果修訂版本可佈建,也就是說在收購修訂版本時不會產生合併衝突,機器人就會建立新的提取要求。當 Bazel 團隊的成員核准提取要求時,系統會精心挑選修訂版本,並將修訂版本合併至發布分支版本。如需完整 cherry 挑選要求的視覺範例,請參閱這個範例

  5. 找出發布版本阻礙,並修正系統在版本分支中發現的問題。

    • 在 Bazel CI 上的 postsubmit下游測試管道中,使用相同的測試套件來測試發布分支版本。Bazel 團隊會監控發布分支版本的測試結果,並修正任何發現的迴歸問題。
  6. 解決所有已知的發布區塊後,從發布分支版本建立新的候選版本。

    • 我們也會在 bazel-discuss 上公布這個候選版本,Bazel 團隊會監控該候選項目的社群錯誤報告。
    • 如果發現新的發布攔截器,請返回最後步驟,解決所有問題後,建立新的候選版。
    • 建立第一個候選版本後,就無法將新功能新增至發布分支版本。
  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_SHUTDOWNBAZELISK_CLEAN 環境變數來執行對應的 Bazel 指令,以便在需要重現問題時重設建構狀態。詳情請參閱 Bazelisk Bisect 功能的說明文件。

請記得將 Bazelisk 升級至最新版本,以便使用 Binct 功能。

規則相容性

如果您是規則作者,並想維持與不同 Bazel 版本的相容性,請查看規則相容性頁面。