為了滿足您的需求，Bazel 會持續發展，因此我們想分享 2025 年發展藍圖的最新資訊。
我們預計在 2025 年底推出 Bazel 9.0 長期支援 (LTS)。
全面改用 Bzlmod
自 Bazel 7 起，Bzlmod 已成為 Bazel 的標準外部依附元件系統，取代舊版 WORKSPACE 系統。截至 2025 年 3 月，Bazel 中央註冊中心已代管超過 650 個模組。
在 Bazel 9 中，我們將完全移除 WORKSPACE 功能，而 Bzlmod 將是導入 Bazel 中外部依附元件的唯一方式。為盡量降低社群的遷移成本，我們將專注於進一步改善遷移指南和工具。
此外，我們希望透過垃圾收集功能，實作改善的共用存放區快取 (請參閱 #12227)，並可能將其回移至 Bazel 8。Bazel 中央註冊中心也將支援驗證 SLSA 認證。
遷移 Android、C++、Java、Python 和 Proto 規則
在 Bazel 8 中，我們已將 Android、Java、Python 和 Proto 規則的支援功能從 Bazel 程式碼庫遷移至各自的存放區中的 Starlark 規則。為了簡化遷移作業，我們在 Bazel 中實作了自動載入功能，可透過 --incompatible_autoload_externally 和 --incompatible_disable_autoloads_in_main_repo 標記進行控制。
在 Bazel 9 中，我們希望預設情況下停用自動載入功能，並要求每個專案明確載入 BUILD 檔案中的必要規則。
我們會將大部分 C++ 語言支援重寫為 Starlark，將其從 Bazel 二進位檔中分離，並移至 /rules_cc 存放區。這是 Bazel 目前仍支援的最後一個主要語言。
我們也將 C++、Java 和 Proto 規則的單元測試移植至 Starlark，並將這些測試移至實作旁的存放區，以提高規則作者的速度。
Starlark 改善項目
Bazel 將能夠延後評估符號巨集。也就是說，如果未要求所宣告的目標，系統就不會執行符號式巨集，進而改善大型套件的效能。
Starlark 將採用實驗型系統，類似於 Python 的型別註解。我們預計在 Bazel 9 推出後，類型系統就會穩定運作。
可設定性
我們的主要目標是減少建構標記的成本和混淆。
我們正在實驗新的專案設定模式，讓使用者不必知道要設定哪個版本和測試旗標。因此，$ bazel test //foo 會根據 foo 專案的政策，自動設定正確的標記。這項功能在 9.0 版中可能仍處於實驗階段，但歡迎提供寶貴意見。
旗標範圍可讓您在 Starlark 旗標離開專案範圍時將其移除，這樣就不會在不需要的間接依附元件上中斷快取。這樣一來，使用轉場的建構作業就能更省錢、更快速。以下舉例說明。我們正在擴充這個概念，以便控制要將哪些標記傳播至執行設定，並考慮提供更彈性的支援，例如自訂 Starlark，以便判斷應將哪些依附元件邊緣傳播標記。
我們會優先將內建語言標記從 Bazel 移至 Starlark，讓這些標記與相關規則定義搭配使用。
改善遠端執行作業
我們計畫新增對非同步執行作業的支援，藉由增加平行作業來加快遠端執行作業。
如要追蹤藍圖更新內容並討論計畫中的功能，請加入 slack.bazel.build 的社群 Slack 伺服器。
這份路線圖旨在向社群說明團隊對 Bazel 9.0 的想法。我們會根據開發人員和客戶的意見回饋，或新市場商機，調整優先順序。