Model Rilis

Laporkan masalah Lihat sumber

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

Pembuatan versi rilis

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

  • Rilis utama berisi fitur yang tidak kompatibel dengan rilis sebelumnya. Setiap versi Bazel utama merupakan rilis LTS.
  • Rilis minor berisi perbaikan bug dan fitur kompatibilitas mundur 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
  • Kecil: 6.1.0
  • Patch: 6.1.2
  • Pra-rilis: 7.0.0-pre.20230502.1

Tahapan dukungan

Untuk setiap versi Bazel utama, ada empat tahap dukungan:

  • Rolling: Versi utama ini masih dalam pra-rilis, tim Bazel memublikasikan rilis berkelanjutan dari HEAD.
  • Aktif: Versi utama ini adalah rilis LTS aktif saat ini. Tim Bazel mem-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 Bazel LTS yang lebih baru.

Ritme rilis

Bazel secara rutin memublikasikan rilis untuk dua jalur rilis.

Rilis berkelanjutan

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

Rilis LTS

  • Rilis utama: Rilis LTS baru diperkirakan akan dipotong dari HEAD kira-kira setiap 12 bulan. Setelah dirilis, LTS baru akan segera memasuki tahap Aktif, dan rilis LTS sebelumnya memasuki tahap Pemeliharaan.
  • Rilis minor: Versi minor baru di jalur Active LTS diharapkan akan dirilis sekali setiap 2 bulan.
  • Rilis patch: Versi patch baru untuk rilis LTS dalam tahap Aktif dan Pemeliharaan diharapkan dirilis sesuai permintaan untuk perbaikan bug penting.
  • Rilis Bazel LTS memasuki tahap yang tidak digunakan lagi setelah berada dalam Tahap pemeliharaan selama 2 tahun.

Untuk rilis terencana, lihat masalah rilis di GitHub.

Matriks dukungan

Rilis LTS Tahap dukungan Versi terbaru Akhir dukungan
Bazel 7 Berkelanjutan Memeriksa halaman rilis GitHub T/A
Bazel 6 Aktif 6.3.2 Des 2025
Bazel 5 Pemeliharaan 5.4.1 Jan 2025
Bazel 4 Pemeliharaan 4.2.4 Jan 2024

Semua rilis Bazel dapat ditemukan di halaman rilis di GitHub.

Prosedur & kebijakan rilis

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

Untuk rilis LTS, prosedur dan kebijakan di bawah diikuti:

  1. Tentukan commit dasar untuk rilis.
    • Untuk rilis LTS utama yang baru, commit dasar pengukurannya adalah HEAD cabang utama.
    • Untuk rilis minor atau patch, commit dasar pengukuran adalah HEAD pada versi terbaru saat ini dari rilis LTS yang sama.
  2. Buat cabang rilis atas nama release-<version> dari commit dasar pengukuran.
  3. Backport berubah melalui PR ke cabang rilis.
    • Komunitas dapat menyarankan commit tertentu untuk di-backport dengan membalas "@bazel-io flag" terkait masalah GitHub atau PR yang relevan untuk menandainya sebagai potensi rilis, tim Bazel mengelompokkannya dan memutuskan apakah akan men-backport commit.
    • Hanya commit yang kompatibel dengan versi sebelumnya di cabang utama yang dapat di-backport, perubahan kecil tambahan untuk mengatasi konflik penggabungan dapat diterima.
  4. Mengidentifikasi pemblokir rilis dan memperbaiki masalah yang ditemukan di cabang rilis.
    • Cabang rilis diuji dengan rangkaian pengujian yang sama di postsubmit dan pipeline pengujian downstream pada Bazel CI. Tim Bazel memantau hasil pengujian cabang rilis dan memperbaiki regresi yang ditemukan.
  5. Buat kandidat rilis baru dari cabang rilis jika semua pemblokir rilis yang diketahui telah di-resolve.
    • Kandidat rilis diumumkan di bazel-discuss, tim Bazel memantau laporan bug komunitas untuk kandidat.
    • 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, kirim rilis setidaknya dua hari kerja setelah kandidat rilis terakhir keluar.
    • Untuk rilis utama dan kecil, kirim rilis dua hari kerja setelah kandidat rilis terakhir dirilis, tetapi tidak lebih awal dari satu minggu setelah kandidat rilis pertama dirilis.
    • Rilis hanya dikirim pada hari dengan hari kerja berikutnya.
    • Rilis ini diumumkan pada bazel-discuss, tim Bazel memantau dan menangani laporan bug komunitas untuk rilis baru.

Melaporkan regresi

Jika pengguna menemukan regresi dalam rilis Bazel baru, kandidat rilis, atau bahkan Bazel di HEAD, laporkan bug di GitHub. Anda dapat menggunakan Bazelisk untuk membagi commit penyebab 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 membagi dua 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 merekonstruksi masalah. Untuk mengetahui detail selengkapnya, lihat dokumentasi tentang fitur pembagian Bazelisk.

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

Kompatibilitas aturan

Jika Anda adalah pembuat aturan dan ingin mempertahankan kompatibilitas dengan versi Bazel yang berbeda, lihat halaman Kompatibilitas Aturan.