Model Rilis

Laporkan masalah Lihat sumber Malam · 7,2 · 7,1 · 7,0 · 6,5 · 6,4

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.

Matriks dukungan

Rilis LTS Tahap dukungan Versi terbaru Akhir dukungan
Bazel 8 Berkelanjutan Periksa halaman rilis berkelanjutan T/A
Bazel 7 Aktif 7.2.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 rilis di GitHub.

Pembuatan versi rilis

Bazel menggunakan major.minor.patch Semantik Skema pembuatan versi.

  • Rilis utama berisi fitur yang tidak kompatibel dengan versi sebelumnya rilis sebelumnya. Setiap versi utama Bazel adalah rilis LTS.
  • Rilis minor berisi perbaikan bug dan fitur yang kompatibel dengan versi lama di-back-port 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 setiap jenis akan menghasilkan nomor versi berikut:

  • Besar: 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:

  • Diluncurkan: Versi utama ini masih dalam tahap pra-rilis, oleh tim Bazel memublikasikan rilis berkelanjutan 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 {i>backport<i} perbaikan {i>bug<i} penting untuk keamanan dan masalah kompatibilitas OS ke dalam 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 berkelanjutan 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 sekitar 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 setiap 2 bulan sekali.
  • Rilis patch: Versi patch baru untuk rilis LTS di Active dan Tahap pemeliharaan diharapkan akan dirilis sesuai permintaan untuk bug kritis sejumlah perbaikan.
  • Rilis LTS Bazel memasuki tahap Tidak digunakan lagi setelah berada di Tahap pemeliharaan selama 2 tahun.

Untuk rilis terencana, lihat rilis kami masalah di GitHub.

Prosedur rilis & kebijakan

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

Untuk rilis LTS, prosedur dan kebijakan di bawah diikuti:

  1. Tentukan commit dasar untuk rilis.
    • Untuk rilis LTS besar yang baru, commit dasar pengukuran adalah HEAD dari .
    • Untuk rilis minor atau patch, commit dasar pengukuran adalah HEAD versi terbaru dari rilis LTS yang sama.
  2. Membuat cabang rilis dengan nama release-<version> dari dasar pengukuran dan melakukan commit.
  3. Melakukan 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.
  4. Perubahan backport menggunakan Masalah Permintaan Pilihan Cherry untuk pengelola Bazel.

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

      1. Buka permintaan pengambilan keputusan
      2. Isi detail permintaan
        • Judul: Berikan judul yang ringkas dan deskriptif untuk permintaan.
        • ID Commit: Masukkan ID commit yang ingin Anda pilihan terbaik. Jika ada beberapa commit, pisahkan dengan koma.
        • Kategori: Tentukan kategori permintaan.
        • Peninjau: Untuk beberapa pengulas, pisahkan GitHub mereka ID dengan koma.
      3. Tetapkan {i>milestone<i}
        • Temukan "Pencapaian" lalu klik setelan.
        • Pilih pemblokir rilis X.Y.Z yang sesuai. Tindakan ini akan memicu bot pilihan utama untuk memproses permintaan Anda untuk "release-X.Y.Z" .
      4. Kirim Masalah
        • Setelah semua detail diisi dan miestone ditetapkan, mengirimkan masalah.
    • Bot pilihan utama akan memproses permintaan itu dan memberi tahu jika komitmen memenuhi syarat untuk dipilih. Jika commit-nya dapat dipilih, yang berarti tidak ada menggabungkan konflik sambil memilih komitmen, lalu bot akan membuat permintaan pull baru. Saat tarikan disetujui oleh anggota tim Bazel, yaitu commit dipilih dan digabungkan ke cabang rilis. Untuk contoh visual dari permintaan {i>cermin<i} yang telah selesai, rujuk ke ini contoh kami.

  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 pada Bazel CI. Tim Bazel memantau hasil pengujian rilis tersebut dan memperbaiki regresi yang ditemukan.
  6. Membuat kandidat rilis baru dari cabang rilis jika semuanya sudah diketahui pemblokir rilis telah diselesaikan.

    • Kandidat rilis diumumkan pada diskusi-bazel, tim Bazel memantau laporan {i> bug<i} komunitas untuk kandidat tersebut.
    • 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; pilihan tidak dibatasi hingga hanya perbaikan. Jika memerlukan jawaban terbaik, pemohon harus menjawab pertanyaan berikut: Mengapa perubahan ini penting, dan apa manfaatnya yang dihasilkannya? Bagaimana kemungkinan perubahan ini memunculkan regresi?
  7. Mengirim kandidat rilis sebagai rilis resmi jika tidak ada rilis lebih lanjut pemblokir ditemukan

    • Untuk rilis patch, kirim rilis setidaknya dua hari kerja setelah kandidat rilis terakhir keluar.
    • Untuk rilis besar dan kecil, dorong rilis tersebut dua hari kerja setelah kandidat rilis terakhir keluar, tetapi tidak lebih awal dari satu minggu setelahnya kandidat rilis pertama keluar.
    • 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 akan membaginya menjadi dua pelaku dan menyertakan informasi ini dalam bug laporan.

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 dijalankan perintah bazel yang sesuai untuk mengatur ulang status build jika diperlukan untuk mereproduksi masalah. Untuk detail selengkapnya, baca dokumentasi tentang Bazelisk fitur dua.

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

Kompatibilitas aturan

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