Lansman Modeli

Sorun bildirin Kaynağı göster

Orijinal blog yayınında duyurulduğu gibi Bazel 4.0 ve daha yüksek sürümleri, iki sürüm kanalı için destek sağlar: süreli sürümler ve uzun süreli destek (LTS) sürümleri. Bu sayfada Bazel'in sürüm modeliyle ilgili en son bilgiler ele alınıyor.

Destek matrisi

LTS sürümü Destek aşaması Son sürüm Destek sonu
Bazel 8 Daimi Aşamalı sürüm sayfasını kontrol etme Yok
Bazel 7 Etkin 7.1.1 Aralık 2026
Bazel 6 Bakım 6.5.0 Aralık 2025
Bazel 5 Bakım 5.4.1 Ocak 2025
Bazel 4 Kullanımdan kaldırıldı 4.2.4 Ocak 2024

Tüm Bazel LTS sürümleri GitHub'daki sürüm sayfasında bulunabilir.

Sürüm oluşturma

Bazel, bir major.minor.patch Anlamsal Sürüm Oluşturma şeması kullanır.

  • Ana sürüm, önceki sürümle geriye dönük uyumlu olmayan özellikler içerir. Bazel'ın her ana sürümü bir LTS sürümüdür.
  • Küçük bir sürüm, eski sürümle uyumlu hata düzeltmeleri ve ana daldan geriye dönük olarak bağlanan özellikler içerir.
  • Yama sürümü, kritik hata düzeltmelerini içerir.

Ayrıca yayın öncesi sürümler, bir sonraki ana sürüm numarasına kısa çizgi ve tarih son eki eklenerek belirtilir.

Örneğin, her türün yeni bir sürümü şu sürüm numaralarıyla sonuçlanır:

  • Büyük: 6.0.0
  • Küçük: 6.1.0
  • Yama: 6.1.2
  • Yayın öncesi: 7.0.0-ön.20230502.1

Destek aşamaları

Her Bazel ana sürümü için dört destek aşaması vardır:

  • Hareketli: Bu ana sürüm hâlâ yayın öncesi aşamadadır. Bazel ekibi HEAD kaynağından periyodik sürümleri yayınlar.
  • Etkin: Bu ana sürüm, mevcut etkin LTS sürümüdür. Bazel ekibi, önemli özellikleri ve hata düzeltmelerini küçük sürümlerine geri aktarıyor.
  • Bakım: Bu ana sürüm, bakım modundaki eski bir LTS sürümüdür. Bazel ekibi, güvenlik sorunlarına ve işletim sistemi uyumluluğu sorunlarına yönelik kritik hata düzeltmelerini bu LTS sürümüne yalnızca geri taşıma sözü veriyor.
  • Kullanımdan kaldırıldı: Bazel ekibi artık bu ana sürüm için destek sağlamamaktadır. Tüm kullanıcılar, daha yeni Bazel LTS sürümlerine geçmelidir.

Yayın sıklığı

Bazel, iki sürüm kanalı için düzenli olarak sürüm yayınlar.

Periyodik sürümler

  • Periyodik sürümler Google Blaze sürümüyle koordine edilir ve iki haftada bir HEAD sayfasından yayınlanır. Bu, bir sonraki Bazel LTS sürümünün önizlemesidir.
  • Periyodik sürümler uyumlu olmayan değişiklikler gönderebilir. Büyük çaplı değişiklikler için uyumsuz işaretler önerilir. Uyumsuz değişiklikleri kullanıma sunmak geriye dönük uyumluluk politikamıza uygun olmalıdır.

LTS sürümleri

  • Ana sürüm: Yeni bir LTS sürümünün HEAD'ten yaklaşık 12 ayda bir kesilmesi beklenmektedir. Yeni bir LTS sürümü çıktığında hemen Etkin aşamasına geçer ve önceki LTS sürümü Bakım aşamasına geçer.
  • Küçük sürüm: Active LTS kanalındaki yeni küçük sürümlerin 2 ayda bir yayınlanması beklenmektedir.
  • Yama sürümü: Etkin ve Bakım aşamalarındaki LTS sürümleri için yeni yama sürümlerinin, kritik hata düzeltmeleri için isteğe bağlı olarak yayınlanması beklenmektedir.
  • Bazel LTS sürümü, 2 yıl boyunca Bakım aşamasında olduktan sonra Desteği sonlandırılan aşamaya girer.

Planlanan sürümler için lütfen GitHub'daki sürüm sorunlarımıza göz atın.

Yayın prosedürü ve politikaları

Periyodik sürümler için süreç basittir: Yaklaşık iki haftada bir, Google'ın dahili Blaze sürümüyle aynı temel çizgiye uygun yeni bir sürüm oluşturulur. Hızlı sürüm planı nedeniyle, kullanıma sunulan sürümlerde yapılan hiçbir değişikliği geri yüklemeyiz.

LTS sürümleri için aşağıdaki prosedür ve politikalara uyulur:

  1. Sürüm için temel kayıt belirleyin.
    • Yeni bir ana LTS sürümü için temel kaydetme, ana dalın HEAD öğesidir.
    • Küçük veya yama sürümü için referans kaydetme, aynı LTS sürümünün mevcut en son sürümünün HEAD değeridir.
  2. Temel taahhütten release-<version> adında bir sürüm dalı oluşturun.
  3. PR'ler aracılığıyla yapılan geri yükleme değişikliklerinin sürüm dalına aktarılması.
    • Topluluk, ilgili GitHub sorunları veya PR'leri için "@bazel-io flag" yanıtını göndererek belirli kayıtların geri taşınmasını önerebilir. Bu tür kayıtların, potansiyel yayın engelleyiciler olarak işaretlenmesi için Bazel ekibi bunları önceliklendirir ve kayıtları geri bağlantılandırıp taşımamaya karar verir.
    • Yalnızca ana daldaki geriye dönük uyumlu kaydetmeler geri taşınabilir. Birleştirme çakışmalarını çözmeye yönelik ek küçük değişiklikler kabul edilebilir.
  4. Bazel işleyicileri için Cherry-Seçme İsteği Sorunu ile geri yükleme değişiklikleri.

    • Bazel bakım sorumluları, bir yayın dalı için belirli kayıtları özenle seçme isteğinde bulunabilir. Bu süreç, GitHub'da bir "cherry-pick" isteği oluşturularak başlatılır. Bunu şu şekilde yapabilirsiniz:

      1. Cherry-pick isteğini açın.
      2. İstek ayrıntılarını girin
        • Başlık: İstek için kısa ve açıklayıcı bir başlık girin.
        • Kaydetme Kimlikleri: Seçmek istediğiniz kaydetmelerin kimliklerini girin. Birden fazla kaydetme varsa bunları virgülle ayırın.
        • Kategori: İsteğin kategorisini belirtin.
        • İncelemeciler: Birden fazla yorumcu için GitHub kimliklerini virgülle ayırın.
      3. Ara hedefi belirleyin
        • "Ara hedef" bölümünü bulun ve ayarı tıklayın.
        • Uygun X.Y.Z yayın engelleyicileri seçin. Bu işlem, "X.Y.Z sürümü" dalı isteğinizi işleme almak için tadım botunu tetikler.
      4. Sayıyı gönderin
        • Tüm ayrıntılar doldurulduktan ve hedef belirlendikten sonra sorunu gönderin.
    • Cherry-pick bot, isteği işleme alır ve kayıtların kiraz seçme için uygun olup olmadığını bildirir. Kaydetme işlemi seçilebilir nitelikteyse, yani kaydetme seçimi sırasında birleştirme çakışması olmuyorsa bot yeni bir pull isteği oluşturur. Pull isteği Bazel ekibinin bir üyesi tarafından onaylandığında, taahhütler özenle seçilir ve yayınlama dalıyla birleştirilir. Tamamlanmış bir kiraz-seçme isteğinin görsel bir örneği için bu örneğe bakın.

  5. Sürüm engelleyicileri belirleyin ve sürüm dalında bulunan sorunları düzeltin.

  6. Bilinen tüm sürüm engelleyiciler çözüldüğünde sürüm dalından yeni bir sürüm adayı oluşturun.

    • Yayın adayı bazel-discuss'da duyurulur. Bazel ekibi aday için topluluk hata raporlarını izler.
    • Yeni sürüm engelleyiciler tanımlanırsa son adıma geri dönün ve tüm sorunları giderdikten sonra yeni bir sürüm adayı oluşturun.
    • İlk sürüm adayı oluşturulduktan sonra sürüm dalına yeni özelliklerin eklenmesine izin verilmez.
  7. Yayın engelleyici başka hiçbir şey bulunamazsa yayın adayını resmi yayın olarak itmek

    • Yama sürümleri için, son sürüm adayı yayınlandıktan en az iki iş günü sonra sürümü yayınlayın.
    • Ana ve küçük sürümler için, son yayın adayının çıkış tarihinden iki iş günü sonra, ancak ilk yayın adayının çıkış tarihinden en fazla bir hafta sonra sürümü yayınlayın.
    • Sürüm yalnızca sonraki günün iş günü olduğu bir günde aktarılır.
    • Sürüm bazel-discuss'da duyurulur. Bazel ekibi yeni sürüm için topluluk hata raporlarını izler ve ele alır.

Regresyonları bildirme

Bir kullanıcı yeni bir Bazel sürümünde, serbest bırakma adayında, hatta HEAD öğesinde Bazel'da bir regresyon bulursa lütfen GitHub'da hata bildiriminde bulunun. Hatalı kaydı bölmek ve bu bilgileri hata raporuna eklemek için Bazelisk'i kullanabilirsiniz.

Örneğin, derlemeniz Bazel 6.1.0 ile başarılı olursa ancak ikinci sürüm adayı olan 6.2.0 ile başarısız olursa,

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

BAZELISK_SHUTDOWN veya BAZELISK_CLEAN ortam değişkenini, sorunun yeniden oluşturulması gerektiğinde derleme durumunu sıfırlamak amacıyla ilgili Bazel komutlarını çalıştıracak şekilde ayarlayabilirsiniz. Daha fazla bilgi için Bazelisk bisect özelliği ile ilgili belgelere göz atın.

Bisect özelliğini kullanmak için Bazelisk'i en son sürüme yükseltmeyi unutmayın.

Kural uyumluluğu

Kural yazarsıysanız ve farklı Bazel sürümleriyle uyumluluğu sürdürmek istiyorsanız lütfen Kural Uyumluluğu sayfasına göz atın.