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 berkelanjutan dan rilis dukungan jangka panjang (LTS). Halaman ini membahas informasi terbaru tentang model rilis Bazel.

Matriks dukungan

Rilis LTS Tahap dukungan Versi terbaru Akhir dukungan
Bazel 8 Berkelanjutan Periksa halaman rilis berkelanjutan T/A
Bazel 7 Aktif 7.1.1 Des 2026
Bazel 6 Pemeliharaan 6.5.0 Des 2025
Bazel 5 Pemeliharaan 5.4.1 Januari 2025
Bazel 4 Tidak digunakan lagi 4.2.4 Januari 2024

Semua rilis Bazel LTS dapat ditemukan di halaman rilis di GitHub.

Pembuatan versi rilis

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

  • Rilis utama berisi fitur yang tidak kompatibel dengan rilis sebelumnya. Setiap versi utama Bazel adalah rilis LTS.
  • Rilis minor berisi perbaikan bug yang kompatibel dengan versi lama dan fitur 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 ini:

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

Tahapan dukungan

Untuk setiap versi utama Bazel, ada empat tahap dukungan:

  • Rolling: 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 dalam 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 dalam 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 setiap dua minggu. Ini adalah pratinjau rilis Bazel LTS berikutnya.
  • Rilis berkelanjutan dapat mengirimkan perubahan yang tidak kompatibel. Tanda yang tidak kompatibel direkomendasikan untuk perubahan besar yang dapat menyebabkan gangguan. Meluncurkan perubahan 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 rilis LTS baru dirilis, rilis akan langsung memasuki tahap Aktif, dan rilis LTS sebelumnya memasuki tahap Pemeliharaan.
  • Rilis minor: Versi minor baru di jalur LTS Aktif diperkirakan akan dirilis setiap 2 bulan sekali.
  • Rilis patch: Versi patch baru untuk rilis LTS dalam tahap Aktif dan Pemeliharaan diperkirakan akan dirilis sesuai permintaan untuk perbaikan bug penting.
  • Rilis Bazel LTS memasuki tahap Tidak digunakan lagi setelah berada dalam tahap Pemeliharaan selama 2 tahun.

Untuk rilis terencana, lihat masalah rilis kami di GitHub.

Prosedur & kebijakan rilis

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

Untuk rilis LTS, prosedur dan kebijakan berikut diikuti:

  1. Tentukan commit dasar untuk rilis.
    • Untuk rilis utama LTS utama yang baru, commit dasar pengukuran adalah HEAD cabang utama.
    • Untuk rilis minor atau patch, commit dasar pengukuran adalah HEAD dari versi terbaru rilis LTS yang sama saat ini.
  2. Buat cabang rilis dengan nama release-<version> dari commit dasar pengukuran.
  3. Mem-backport perubahan melalui PR ke cabang rilis.
    • Komunitas dapat menyarankan commit tertentu untuk di-backport dengan membalas "@bazel-io flag" pada masalah GitHub yang relevan atau PR untuk menandainya sebagai penghambat rilis yang potensial, tim Bazel akan memprioritaskannya dan memutuskan apakah akan mem-backport commit tersebut atau tidak.
    • Hanya commit yang kompatibel dengan versi lama pada cabang utama yang dapat di-backport, perubahan kecil tambahan untuk menyelesaikan konflik penggabungan dapat diterima.
  4. Backport perubahan menggunakan Masalah Permintaan Cherry-choose untuk pengelola Bazel.

    • Pengelola Bazel dapat meminta untuk memilih commit khusus tertentu untuk cabang rilis. Proses ini dimulai dengan membuat permintaan pilihan di GitHub. Berikut cara melakukannya.

      1. Buka permintaan pilihan
      2. Isi detail permintaan
        • Judul: Berikan judul yang ringkas dan deskriptif untuk permintaan.
        • ID Commit: Masukkan ID commit yang ingin Anda pilih. Jika ada beberapa commit, pisahkan dengan koma.
        • Kategori: Menentukan kategori permintaan.
        • Peninjau: Untuk beberapa peninjau, pisahkan ID GitHub mereka dengan koma.
      3. Tetapkan pencapaian
        • Temukan bagian "Pencapaian" dan klik setelan.
        • Pilih pemblokir rilis X.Y.Z yang sesuai. Tindakan ini akan memicu bot memilih sakura guna memproses permintaan Anda untuk cabang "release-X.Y.Z".
      4. Kirimkan Masalah
        • Setelah semua detail diisi dan miestone ditetapkan, kirimkan masalah.
    • Bot memilih ceri akan memproses permintaan dan memberi tahu jika commit memenuhi syarat untuk pemilihan. Jika commit dapat dipilih secara sakura, yang berarti tidak ada konflik penggabungan saat memilih commit untuk memilih commit, bot akan membuat permintaan pull baru. Saat permintaan pull disetujui oleh anggota tim Bazel, commit akan dipilih secara sakura dan digabungkan ke cabang rilis. Untuk contoh visual permintaan memilih ceri yang telah selesai, lihat contoh ini.

  5. 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 di Bazel CI. Tim Bazel memantau hasil pengujian cabang rilis dan memperbaiki regresi yang ditemukan.
  6. Membuat 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 teridentifikasi, kembali ke langkah terakhir dan buat kandidat rilis baru setelah menyelesaikan semua masalah.
    • Fitur baru tidak diizinkan untuk ditambahkan ke cabang rilis setelah kandidat rilis pertama dibuat.
  7. Mendorong kandidat rilis sebagai rilis resmi jika tidak ditemukan pemblokir rilis lebih lanjut

    • Untuk rilis patch, kirim rilis setidaknya dua hari kerja setelah kandidat rilis terakhir keluar.
    • Untuk rilis besar dan minor, kirim rilis dua hari kerja setelah kandidat rilis terakhir keluar, tetapi tidak lebih awal dari satu minggu setelah kandidat rilis pertama keluar.
    • Rilis hanya dikirim pada hari saat hari berikutnya adalah hari kerja.
    • Rilis diumumkan di bazel-discuss, tim Bazel memantau dan menangani laporan bug komunitas untuk rilis baru tersebut.

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 dua commit pelaku 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 menyetel variabel lingkungan BAZELISK_SHUTDOWN atau BAZELISK_CLEAN untuk menjalankan perintah bazel yang sesuai guna mereset status build jika diperlukan untuk mereproduksi masalah. Untuk detail selengkapnya, lihat dokumentasi tentang fitur dua kali Bazelisk.

Jangan lupa mengupgrade Bazelisk ke versi terbaru untuk menggunakan fitur bisect.

Kompatibilitas aturan

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