Seperti yang diumumkan dalam postingan blog asli, Bazel 4.0 dan versi yang lebih tinggi memberikan dukungan untuk dua jalur rilis: rilis rolling 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 10 | Berkelanjutan | Memeriksa halaman rilis berkelanjutan | T/A |
| Bazel 9 | Aktif | 9.3.1 | Des 2028 |
| Bazel 8 | Pemeliharaan | 8.8.2 | Des 2027 |
| Bazel 7 | Pemeliharaan | 7.7.2 | Des 2026 |
| Bazel 6 | Tidak digunakan lagi | 6.6.0 | Des 2025 |
| Bazel 5 | Tidak digunakan lagi | 5.4.1 | Jan 2025 |
| Bazel 4 | Tidak digunakan lagi | 4.2.4 | Jan 2024 |
Semua rilis LTS Bazel dapat ditemukan di halaman rilis di GitHub. Badge "Latest" di GitHub selalu mengarah ke versi semantik tertinggi, meskipun patch pemeliharaan untuk versi yang lebih lama dirilis lebih baru.
Pembuatan versi rilis
Bazel menggunakan skema Pembuatan Versi Semantik major.minor.patch.
- Rilis utama berisi fitur yang tidak kompatibel dengan versi lama dari 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 untuk setiap jenis akan menghasilkan nomor versi berikut:
- Major: 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:
- 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 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 sekitar setiap dua minggu. Ini adalah pratinjau rilis LTS Bazel berikutnya.
- Rilis berkelanjutan dapat mengirimkan perubahan yang tidak kompatibel. Flag yang tidak kompatibel direkomendasikan untuk perubahan yang dapat menyebabkan gangguan besar, peluncuran 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 diluncurkan, 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 sekali.
- 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.
Prosedur & kebijakan rilis
Untuk rilis berkelanjutan, prosesnya mudah: sekitar setiap dua minggu, rilis baru dibuat, yang selaras dengan dasar pengukuran yang sama dengan rilis Blaze internal Google. Karena jadwal rilis yang cepat, kami tidak melakukan backport perubahan apa pun pada rilis berkelanjutan.
Untuk rilis LTS, prosedur dan kebijakan berikut akan diikuti:
- Tentukan commit dasar pengukuran 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 dari versi terbaru saat ini dari rilis LTS yang sama.
- Buat cabang rilis dengan nama
release-<version>dari commit dasar pengukuran. - Melakukan 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 melakukan triase dan memutuskan apakah akan melakukan backport pada commit tersebut. - 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
"
Backport perubahan menggunakan Masalah Permintaan Cherry-Pick untuk pengelola Bazel.
Pengelola Bazel dapat meminta untuk memilih commit tertentu ke cabang rilis. Proses ini dimulai dengan membuat permintaan cherry-pick di GitHub. Berikut cara melakukannya.
- Buka permintaan cherry-pick
- 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: Tentukan kategori permintaan.
- Reviewer(s): Untuk beberapa peninjau, pisahkan ID GitHub mereka dengan koma.
- Tetapkan pencapaian
- Temukan bagian "Pencapaian", lalu klik setelan.
- Pilih pemblokir rilis X.Y.Z yang sesuai. Tindakan ini akan memicu bot cherry-pick untuk memproses permintaan Anda untuk cabang "release-X.Y.Z".
- Laporkan Masalah
- Setelah semua detail diisi dan milestone ditetapkan, kirimkan masalah.
Bot cherry-pick akan memproses permintaan dan memberi tahu jika commit memenuhi syarat untuk cherry-pick. Jika commit dapat di-cherry-pick, yang berarti tidak ada konflik penggabungan saat melakukan cherry-pick commit, bot akan membuat permintaan pull baru. Saat permintaan pull disetujui oleh anggota tim Bazel, commit akan dipilih dan digabungkan ke cabang rilis. Untuk contoh visual permintaan cherry-pick yang telah selesai, lihat contoh ini .
Identifikasi pemblokir rilis dan perbaiki masalah yang ditemukan di cabang rilis.
- Cabang rilis diuji dengan suite pengujian yang sama di postsubmit dan pipeline pengujian downstream di 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 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; cherry-pick dibatasi hanya untuk perbaikan penting. Jika cherry-pick diperlukan, pemohon harus menjawab pertanyaan berikut: Mengapa perubahan ini penting, dan apa manfaat yang diberikannya? Seberapa besar kemungkinan perubahan ini menyebabkan regresi?
Mendorong kandidat rilis sebagai rilis resmi jika tidak ditemukan lagi pemblokir rilis
- 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 keluar, tetapi tidak lebih awal dari satu minggu setelah kandidat rilis pertama keluar.
- Rilis hanya dikirim pada hari yang diikuti oleh hari kerja.
- Rilis diumumkan di 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 dua commit penyebab dan menyertakan informasi ini dalam laporan bug.
Misalnya, jika build Anda berhasil dengan Bazel 6.1.0, tetapi gagal dengan rilis kandidat 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.
Jangan lupa 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.