Lansman Modeli

İlk blog yazısında duyurulduğu gibi, Bazel 4.0 ve sonraki sürümler iki yayın kanalını destekler: sürekli yayınlar ve uzun süreli destek (LTS) yayınları. Bu sayfada, Bazel'in yayın modeliyle ilgili en son bilgiler yer almaktadır.

Destek matrisi

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

Sürüm sürümü

Bazel, major.minor.patch Anlamsal Sürümleme şemasını kullanır.

• Büyük sürümlerde, önceki sürümle geriye dönük uyumlu olmayan özellikler bulunur. Bazel'in her büyük sürümü bir LTS sürümüdür.
• Ara sürüm, geriye dönük olarak uyumlu hata düzeltmeleri ve ana daldan geri aktarılan özellikleri içerir.
• Yama sürümü, önemli hata düzeltmelerini içerir.

Ayrıca, yayın öncesi sürümler, bir sonraki ana sürüm numarasına tire ve tarih soneki eklenerek belirtilir.

Örneğin, her türden yeni bir sürüm şu sürüm numaralarını oluşturur:

• Büyük: 6.0.0
• Küçük: 6.1.0
• Yama: 6.1.2
• Lansman öncesi sürüm: 7.0.0-pre.20230502.1

Destek aşamaları

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

• Rolling: Bu ana sürüm henüz yayın öncesi aşamasındadır. Bazel ekibi, HEAD'den rolling sürümler yayınlar.
• Aktif: Bu ana sürüm, şu anda etkin olan LTS sürümüdür. Bazel ekibi, önemli özellikleri ve hata düzeltmelerini küçük sürümlerine geri aktarır.
• Bakım: Bu ana sürüm, bakım modunda eski bir LTS sürümüdür. Bazel ekibi, yalnızca güvenlik sorunları ve işletim sistemi uyumluluğu sorunlarıyla ilgili kritik hata düzeltmelerini bu LTS sürümüne geri aktarmayı garanti eder.
• Desteği sonlandırıldı: Bazel ekibi artık bu ana sürüm için destek sağlamıyor. Tüm kullanıcılar daha yeni Bazel LTS sürümlerine geçmelidir.

Serbest bırakma ritmi

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

Sürekli sürümler

• Aşamalı sürümler, Google Blaze sürümüyle koordine edilir ve yaklaşık iki haftada bir HEAD'den yayınlanır. Bu, bir sonraki Bazel LTS sürümünün önizlemesidir.
• Sürekli sürümler uyumsuz değişiklikler getirebilir. Uyumsuz değişikliklerin kullanıma sunulması, geriye dönük uyumluluk politikamıza uygun olmalıdır. Uyumsuz değişiklikler, büyük çaplı uyumsuzluklara neden olan değişiklikler için önerilir.

LTS sürümleri

• Ana sürüm: Yaklaşık 12 ayda bir HEAD'den yeni bir LTS sürümünün oluşturulması bekleniyor. Yeni bir LTS sürümü çıktığında, hemen Aktif aşamaya girer ve önceki LTS sürümü Bakım aşamasına girer.
• Küçük sürüm: Etkin LTS kanalındaki yeni küçük sürümlerin 2 ayda bir yayınlanması beklenir.
• Yama sürümü: Etkin ve bakım aşamasındaki LTS sürümleri için yeni yama sürümlerinin, kritik hata düzeltmeleri için talep üzerine yayınlanması beklenmektedir.
• Bazel LTS sürümü, 2 yıl boyunca Bakım aşamasında kaldıktan sonra Kullanımdan Kaldırıldı aşamasına girer.

Planlanan sürümler için lütfen Github'daki sürüm sorunlarımızı kontrol edin.

Yayınlama prosedürü ve politikaları

Kademeli yayınlarda süreç basittir: Yaklaşık iki haftada bir, Google'ın dahili Blaze yayınıyla aynı temele uygun yeni bir yayın oluşturulur. Hızlı sürüm takvimi nedeniyle, hiçbir değişikliği yuvarlanan sürümlere geri aktarmıyoruz.

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

1. Yayın için temel bir commit belirleyin.
   • Yeni bir ana LTS sürümünde temel alınan commit, ana dalın HEAD'idir.
   • Küçük veya yama sürümü için temel commit, aynı LTS sürümünün geçerli son sürümünün HEAD'idir.
2. Temel alınan commit'ten release-<version> adına bir yayın dalı oluşturun.
3. Değişiklikleri PR'ler aracılığıyla sürüm dalına geri taşıyın.
   • Topluluk, ilgili GitHub sorunlarına veya PR'lere "@bazel-io flag" yanıtını göndererek belirli commit'lerin geri taşınmasını önerebilir ve bunları potansiyel sürüm engelleyicileri olarak işaretleyebilir, Bazel ekibi bunları sınıflandırır ve commit'lerin geri taşınıp taşınmayacağına karar verir.
   • Yalnızca ana daldaki geriye dönük uyumlu işlemeler geri aktarılabilir. Birleştirme çakışmalarını çözmek için yapılan ek küçük değişiklikler kabul edilebilir.

4. Bazel bakımcıları için Cherry-Pick Request Issue'yu kullanarak değişiklikleri geri taşıyın.

   • Bazel'in bakımını yapanlar, belirli commit'lerin bir yayın dalına seçilmesini isteyebilir. Bu işlem GitHub'da cherry-pick isteği oluşturularak başlatılır. İşte nasıl yapılacağı.

     1. Kiraz toplama isteğini açın
     2. İstek ayrıntılarını doldurun.
        • Başlık: İsteğe kısa ve açıklayıcı bir başlık girin.
        • Onaylama Kimliği(leri): Seçmek istediğiniz onaylamaların kimliğini(lerini) girin. Birden fazla commit varsa bunları virgülle ayırın.
        • Kategori: İsteğin kategorisini belirtin.
        • İnceleyenler: Birden fazla inceleyen varsa GitHub kimliklerini virgülle ayırın.
     3. Ara hedefi belirleyin.
        • "Dönüm noktası" bölümünü bulup ayarı tıklayın.
        • Uygun X.Y.Z sürümünü engelleyen sorunları seçin. Bu eylem, kiraz toplama botunun "release-XYZ" dalı için isteğinizi işlemesini tetikler.
     4. Sorunu Gönderme
        • Tüm ayrıntılar doldurulup dönüm noktası ayarlandıktan sonra sorunu gönderin.

   • Cherry-pick bot, isteği işler ve commit'lerin cherry-pick için uygun olup olmadığını bildirir. Eğer commit'ler seçilebilir nitelikteyse, yani commit seçilirken birleştirme çakışması yaşanmıyorsa, bot yeni bir çekme isteği oluşturacaktır. Çekme isteği Bazel ekibinin bir üyesi tarafından onaylandığında, işlemeler seçilerek yayın dalıyla birleştirilir. Tamamlanmış bir cherry-pick isteğinin görsel örneği için bu örneğe bakın.

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

   • Sürüm dalı, Bazel CI'da postsubmit ve downstream test pipeline'daki aynı test paketiyle test edilir. Bazel ekibi, yayın dalının test sonuçlarını izler ve bulunan regresyonları düzeltir.

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

   • Yayın adayı bazel-discuss listesinde duyurulur. Bazel ekibi, aday için topluluk tarafından gönderilen hata raporlarını izler.
   • Yeni sürüm engelleme sorunları tespit edilirse son adıma geri dönün ve tüm sorunları çözdükten sonra yeni bir yayın adayı oluşturun.
   • İlk sürüm adayı oluşturulduktan sonra sürüm dalına yeni özellikler eklenmesine izin verilmez; seçmeli düzeltmeler yalnızca kritik düzeltmelerle sınırlıdır. Seçme işlemi gerekiyorsa, talep eden kişi şu soruları yanıtlamalıdır: Bu değişiklik neden kritiktir ve ne gibi faydalar sağlar? Bu değişikliğin gerilemeye yol açma olasılığı nedir?

7. Başka sürüm engelleyici bulunmazsa sürüm adayını resmi sürüm olarak yayınlayın.

   • 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.
   • Büyük ve küçük sürümlerde, son sürüm adayı yayınlandıktan iki iş günü sonra sürümü yayınlayın. Ancak ilk sürüm adayı yayınlandıktan bir hafta geçmeden sürümü yayınlamayın.
   • Sürüm yalnızca ertesi günün iş günü olduğu bir günde yayınlanır.
   • Yayın, bazel-discuss listesinde duyurulur. Bazel ekibi, yeni yayınla ilgili topluluk tarafından bildirilen hata raporlarını izler ve ele alır.

Gerilemeleri raporla

Kullanıcılar yeni bir Bazel sürümünde, yayın adayında veya HEAD'deki Bazel'de gerileme tespit ederse lütfen GitHub'da hata bildiriminde bulunun. Bazelisk'i kullanarak suçlu işlemi ikiye bölebilir ve bu bilgiyi hata raporuna ekleyebilirsiniz.

Örneğin, derlemeniz Bazel 6.1.0 ile başarılı olurken 6.2.0'ın ikinci yayın adayıyla başarısız olursa aşağıdaki komutla ikiye bölme işlemi yapabilirsiniz:

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

Sorunu yeniden üretmek için gerekirse yapı durumunu sıfırlamak üzere ilgili bazel komutlarını çalıştırmak üzere BAZELISK_SHUTDOWN veya BAZELISK_CLEAN ortam değişkenini ayarlayabilirsiniz. Daha fazla ayrıntı için Bazelisk'in ikiye bölme özelliği hakkındaki belgelere bakın.

İkiye bölme özelliğini kullanabilmek için Bazelisk'i en son sürüme yükseltmeyi unutmayın.

Kural uyumluluğu

Kural yazarıysanız ve farklı Bazel sürümleriyle uyumluluğu korumak istiyorsanız lütfen Kural Uyumluluğu sayfasını inceleyin.