Model Rilis

Seperti yang diumumkan dalam postingan blog asli, Bazel versi 4.0 dan yang lebih tinggi menyediakan dukungan untuk dua jalur rilis: rilis berkelanjutan dan rilis dukungan jangka panjang (LTS). Halaman ini membahas informasi terbaru tentang model rilis Bazel.

Pemberian versi rilis

Bazel menggunakan skema major.minor.patch Pemberian Versi Semantik.

  • Rilis utama berisi fitur yang tidak kompatibel dengan versi sebelumnya. Setiap versi utama Bazel adalah rilis LTS.
  • Rilis minor berisi perbaikan bug dan fitur yang kompatibel dengan versi sebelumnya yang di-backport dari cabang utama.
  • Rilis patch berisi perbaikan bug penting.

Selain itu, versi pra-rilis ditunjukkan dengan menambahkan tanda hubung dan akhiran tanggal ke nomor versi utama berikutnya.

Misalnya, rilis baru dari setiap jenis akan menghasilkan nomor versi berikut:

  • Utama: 6.0.0
  • Minor: 6.1.0
  • Patch: 6.1.2
  • Pra-rilis: 7.0.0-pre.20230502.1

Tahap dukungan

Untuk setiap versi utama Bazel, ada empat tahap dukungan:

  • Berkelanjutan: Versi utama ini masih dalam tahap pra-rilis, tim Bazel memublikasikan rilis berkelanjutan dari HEAD.
  • Aktif: Versi utama ini adalah rilis LTS aktif saat ini. Tim Bazel melakukan backport fitur penting dan perbaikan bug ke rilis minornya.
  • Pemeliharaan: Versi utama ini adalah rilis LTS lama dalam mode pemeliharaan. Tim Bazel hanya berjanji untuk melakukan backport perbaikan bug penting untuk masalah keamanan dan masalah kompatibilitas OS ke rilis LTS ini.
  • Tidak digunakan lagi: Tim Bazel tidak lagi memberikan dukungan untuk versi utama ini, semua pengguna harus bermigrasi ke rilis LTS Bazel yang lebih baru.

Frekuensi rilis

Bazel secara rutin memublikasikan rilis untuk dua jalur rilis.

Rilis berkelanjutan

  • Rilis berkelanjutan dikoordinasikan dengan rilis Google Blaze dan dirilis dari HEAD sekitar setiap dua minggu. Rilis ini adalah pratinjau rilis LTS Bazel berikutnya.
  • Rilis berkelanjutan dapat mengirimkan perubahan yang tidak kompatibel. Flag yang tidak kompatibel direkomendasikan untuk perubahan besar yang tidak kompatibel. Peluncuran perubahan yang tidak kompatibel harus mengikuti kebijakan kompatibilitas mundur kami.

Rilis LTS

  • Rilis utama: Rilis LTS baru diperkirakan akan dipotong dari HEAD setiap 12 bulan. Setelah rilis LTS baru keluar, rilis tersebut akan langsung memasuki tahap Aktif, dan rilis LTS sebelumnya akan memasuki tahap Pemeliharaan.
  • Rilis minor: Versi minor baru di jalur LTS Aktif diperkirakan akan dirilis setiap 2 bulan.
  • Rilis patch: Versi patch baru untuk rilis LTS dalam tahap Aktif dan Pemeliharaan diperkirakan akan dirilis sesuai permintaan untuk perbaikan bug penting.
  • Rilis LTS Bazel memasuki tahap Tidak Digunakan Lagi setelah berada dalam tahap Pemeliharaan selama 2 tahun.

Untuk rilis yang direncanakan, lihat masalah rilis kami di GitHub.

Matriks dukungan

Rilis LTS Tahap dukungan Versi terbaru Akhir dukungan
Bazel 7 Berkelanjutan Lihat halaman rilis GitHub T/A
Bazel 6 Aktif 6.4.0 Desember 2025
Bazel 5 Pemeliharaan 5.4.1 Januari 2025
Bazel 4 Pemeliharaan 4.2.4 Januari 2024

Semua rilis Bazel dapat ditemukan di halaman rilis di GitHub.

Prosedur &kebijakan rilis

Untuk rilis berkelanjutan, prosesnya sederhana: sekitar setiap dua minggu, rilis baru dibuat, yang selaras dengan dasar yang sama dengan rilis Blaze internal Google. Karena jadwal rilis yang cepat, kami tidak melakukan backport perubahan apa pun ke rilis berkelanjutan.

Untuk rilis LTS, prosedur dan kebijakan di bawah ini diikuti:

  1. Tentukan commit dasar untuk rilis.
    • Untuk rilis LTS utama baru, commit dasar adalah HEAD cabang utama.
    • Untuk rilis minor atau patch, commit dasar adalah HEAD versi terbaru saat ini dari rilis LTS yang sama.
  2. Buat cabang rilis dengan nama release-<version> dari dasar commit.
  3. Lakukan backport perubahan melalui PR ke cabang rilis.
    • Komunitas dapat menyarankan commit tertentu untuk di-backport dengan membalas "@bazel-io flag" pada masalah atau PR GitHub yang relevan untuk menandainya sebagai potensi pemblokir rilis. Tim Bazel akan memprioritaskannya dan memutuskan apakah akan melakukan backport commit.
    • Hanya commit yang kompatibel dengan versi sebelumnya di cabang utama yang dapat di-backport. Perubahan minor tambahan untuk mengatasi konflik gabungan dapat diterima.
  4. Identifikasi pemblokir rilis dan perbaiki masalah yang ditemukan di cabang rilis.
    • Cabang rilis diuji dengan rangkaian pengujian yang sama dalam postsubmit dan pipeline pengujian hilir di Bazel CI. Tim Bazel memantau hasil pengujian cabang rilis dan memperbaiki regresi yang ditemukan.
  5. Buat kandidat rilis baru dari cabang rilis saat semua pemblokir rilis yang diketahui telah diselesaikan.
    • Kandidat rilis diumumkan di bazel-discuss, tim Bazel memantau laporan bug komunitas untuk kandidat tersebut.
    • Jika pemblokir rilis baru diidentifikasi, kembali ke langkah terakhir dan buat kandidat rilis baru setelah menyelesaikan semua masalah.
    • Fitur baru tidak boleh ditambahkan ke cabang rilis setelah kandidat rilis pertama dibuat.
  6. Dorong kandidat rilis sebagai rilis resmi jika tidak ada pemblokir rilis lebih lanjut yang ditemukan
    • Untuk rilis patch, dorong rilis setidaknya dua hari kerja setelah kandidat rilis terakhir keluar.
    • Untuk rilis utama dan minor, dorong rilis dua hari kerja setelah kandidat rilis terakhir keluar, tetapi tidak lebih awal dari satu minggu setelah kandidat rilis pertama keluar.
    • Rilis hanya didorong pada hari di mana hari berikutnya adalah hari kerja.
    • Rilis diumumkan di bazel-discuss, tim Bazel memantau dan mengatasi laporan bug komunitas untuk rilis baru.

Laporkan regresi

Jika pengguna menemukan regresi dalam rilis Bazel baru, kandidat rilis, atau bahkan Bazel di HEAD, ajukan bug di GitHub. Anda dapat menggunakan Bazelisk untuk membagi dua commit yang menyebabkan masalah dan menyertakan informasi ini dalam laporan bug.

Misalnya, jika build Anda berhasil dengan Bazel 6.1.0 tetapi gagal dengan kandidat rilis kedua 6.2.0, Anda dapat melakukan bisect melalui

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

Anda dapat menetapkan variabel lingkungan BAZELISK_SHUTDOWN atau BAZELISK_CLEAN untuk menjalankan perintah bazel yang sesuai guna mereset status build jika diperlukan untuk mereproduksi masalah. Untuk mengetahui detail selengkapnya, lihat dokumentasi tentang fitur bisect Bazelisk .

Ingatlah untuk mengupgrade Bazelisk ke versi terbaru agar dapat menggunakan fitur bisect.

Kompatibilitas aturan

Jika Anda adalah penulis aturan dan ingin mempertahankan kompatibilitas dengan berbagai versi Bazel, lihat halaman Kompatibilitas Aturan.