Seperti yang diumumkan dalam blog asli postingan, Bazel 4.0 dan versi yang lebih tinggi memberikan dukungan untuk dua jalur rilis: peluncuran serta rilis dukungan jangka panjang (LTS). Halaman ini membahas informasi tentang model rilis Bazel.
Pembuatan versi rilis
Bazel menggunakan major.minor.patch Semantik Skema pembuatan versi.
- Rilis utama berisi fitur yang tidak kompatibel dengan rilis sebelumnya. Setiap versi utama Bazel adalah rilis LTS.
- Rilis minor berisi perbaikan bug dan fitur yang kompatibel dengan versi lama 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
- Kecil: 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 versi pra-rilis, tim Bazel memublikasikan rilis rolling dari HEAD.
- Aktif: Versi utama ini adalah rilis LTS aktif saat ini. Bazel tim melakukan backport fitur penting dan perbaikan {i>bug<i} ke dalam rilis minornya.
- Pemeliharaan: Versi utama ini adalah rilis LTS lama yang sedang dalam pemeliharaan mode. 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 semua pengguna harus bermigrasi ke rilis LTS Bazel 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 setiap dua minggu. Ini adalah pratinjau dari Bazel LTS berikutnya data.
- Rilis rolling dapat mengirimkan perubahan yang tidak kompatibel. Tanda yang tidak kompatibel adalah direkomendasikan untuk perubahan besar yang dapat menyebabkan gangguan, meluncurkan perubahan yang tidak kompatibel harus mengikuti kompatibilitas mundur kebijakan kami.
Rilis LTS
- Rilis utama: Rilis LTS baru diperkirakan akan dipotong dari HEAD kira-kira setiap 12 bulan. Setelah dirilis, rilis LTS baru akan segera memasuki dan rilis LTS sebelumnya akan memasuki tahap Pemeliharaan.
- Rilis minor: Versi minor baru di jalur LTS Aktif diperkirakan akan dirilis sekali setiap 2 bulan.
- Rilis patch: Versi patch baru untuk rilis LTS dalam tahap Aktif dan Pemeliharaan diperkirakan akan dirilis sesuai permintaan untuk perbaikan bug kritis.
- Rilis LTS Bazel memasuki tahap Tidak digunakan lagi setelah berada di Tahap pemeliharaan selama 2 tahun.
Untuk rilis yang direncanakan, harap periksa masalah rilis kami di GitHub.
Matriks dukungan
| Rilis LTS | Tahap dukungan | Versi terbaru | Akhir dukungan |
|---|---|---|---|
| Bazel 7 | Berkelanjutan | Periksa halaman rilis GitHub | T/A |
| Bazel 6 | Aktif | 6.4.0 | Dec 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 bertahap, prosesnya mudah: sekitar setiap dua minggu, rilis baru dibuat, yang selaras dengan dasar pengukuran yang sama seperti rilis Blaze internal Google. Karena jadwal rilis yang cepat, kami tidak melakukan backport perubahan apa pun ke rilis rolling.
Untuk rilis LTS, prosedur dan kebijakan di bawah diikuti:
- Tentukan commit dasar untuk rilis.
- Untuk rilis LTS utama baru, commit dasar pengukuran adalah HEAD dari cabang utama.
- Untuk rilis minor atau patch, commit dasar pengukuran adalah HEAD versi terbaru dari rilis LTS yang sama.
- Membuat cabang rilis dengan nama
release-<version>dari dasar pengukuran dan melakukan commit. - Backport perubahan melalui PR ke cabang rilis.
- Komunitas dapat menyarankan commit tertentu untuk di-backport dengan membalas
"
@bazel-io flag" tentang masalah GitHub atau PR yang relevan untuk menandainya sebagai penghambat pelepas, tim Bazel menentukan prioritas dan memutuskan apakah akan melakukan back-port pada commit-nya. - Hanya commit yang kompatibel dengan versi lama di cabang utama yang dapat di-backport, perubahan kecil tambahan untuk menyelesaikan konflik penggabungan dapat diterima.
- Komunitas dapat menyarankan commit tertentu untuk di-backport dengan membalas
"
- Identifikasi pemblokir rilis dan perbaiki 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.
- Buat kandidat rilis baru dari cabang rilis saat semua pemblokir rilis
yang diketahui telah di-resolve.
- Calon rilis diumumkan di bazel-discuss, tim Bazel memantau laporan bug komunitas untuk kandidat.
- Jika pemblokir rilis baru teridentifikasi, kembali ke langkah terakhir dan membuat kandidat rilis baru setelah menyelesaikan semua masalah.
- Fitur baru tidak diizinkan untuk ditambahkan ke cabang rilis setelah kandidat rilis pertama dibuat.
- Kirimkan 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 minor, kirim rilis dua hari kerja setelah kandidat rilis terakhir dirilis, tetapi tidak lebih awal dari satu minggu setelah kandidat rilis pertama dirilis.
- Rilis hanya dikirimkan pada hari saat hari berikutnya adalah bisnis mereka.
- Rilis diumumkan pada diskusi-bazel, tim Bazel memantau dan menangani laporan {i>bug<i} komunitas untuk perangkat data.
Melaporkan regresi
Jika pengguna menemukan regresi dalam rilis Bazel baru, kandidat rilis, atau bahkan Bazel di HEAD, harap laporkan bug di GitHub. Anda dapat menggunakan Bazelisk untuk membagi commit pelaku dan menyertakan informasi ini dalam laporan bug.
Misalnya, jika build Anda berhasil dengan Bazel 6.1.0 tetapi gagal dengan build kedua 6.2.0, Anda dapat membaginya menjadi dua
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 detail selengkapnya, baca dokumentasi tentang Bazelisk
fitur dua.
Jangan lupa untuk 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.