Lansman Modeli

İlk blog yayınında duyurulduğu gibi, Bazel 4.0 ve sonraki sürümler iki yayın kanalı için destek sunar: 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ümlerini GitHub'daki sürüm sayfasında bulabilirsiniz.

Yayın sürümü oluşturma

Bazel, major.minor.patch anlamsal sürüm oluşturma şemasını kullanır.

• Büyük sürümlerde, önceki sürümle geriye dönük uyumlu olmayan özellikler bulunur. Her ana Bazel 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ıyla sonuçlanır:

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

Destek aşamaları

Her büyük 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.
• Etkin: Bu ana sürüm, şu anki etkin LTS sürümüdür. Bazel ekibi, önemli özellikleri ve hata düzeltmelerini küçük sürümlerine geri taşır.
• Bakım: Bu ana sürüm, bakım modundaki 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ı taahhüt 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.

Yayın sıklığı

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

Periyodik yayınlar

• 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.
• Aşamalı yayınlar, uyumsuz değişiklikler içerebilir. Uyumsuzluk işaretleri, büyük ve uyumsuz değişiklikler için önerilir. Uyumsuz değişikliklerin kullanıma sunulması, geriye dönük uyumluluk politikamıza uygun olmalıdır.

LTS sürümleri

• Ana sürüm: Yaklaşık olarak her 12 ayda bir HEAD'den yeni bir LTS sürümünün oluşturulması beklenir. Yeni bir LTS sürümü yayınlandığında hemen Etkin aşamasına girer ve önceki LTS sürümü Bakım aşamasına geçer.
• 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ü: Aktif 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ı inceleyin.

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 olarak yeni bir yayın oluşturulur. Hızlı yayın takvimi nedeniyle, değişiklikleri sürekli yayınlara geri aktarmıyoruz.

LTS sürümlerinde aşağıdaki prosedür ve politikalar uygulanır:

1. Yayın için temel bir commit belirleyin.
   • Yeni bir ana LTS sürümünde, temel taahhüt ana dalın HEAD'idir.
   • Küçük veya yama sürümü için temel taahhüt, aynı LTS sürümünün mevcut en son sürümünün HEAD'idir.
2. Temel alınan commit'ten release-<version> adında bir yayın dalı oluşturun.
3. PR'ler aracılığıyla değişiklikleri yayın dalına geri aktarın.
   • Topluluk, ilgili GitHub sorunlarına veya PR'lara "@bazel-io flag" yanıtını vererek belirli commit'lerin geriye dönük olarak taşınmasını önerebilir. Bu yanıt, commit'leri potansiyel yayın engelleyiciler olarak işaretler. Bazel ekibi, bu commit'leri öncelik sırasına göre değerlendirir ve geriye dönük olarak taşınıp taşınmayacakları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 bir cherry-pick isteği oluşturularak başlatılır. Bunu nasıl yapacağınız aşağıda açıklanmıştır.

     1. Cherry-pick 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.
        • Commit kimlikleri: Cherry-pick yapmak istediğiniz commit'lerin kimliklerini 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 işlem, "release-X.Y.Z" dalı için isteğinizi işlemek üzere cherry-pick botunu tetikler.
     4. Sorunu Gönderme
        • Tüm ayrıntılar doldurulup dönüm noktası ayarlandıktan sonra sorunu gönderin.

   • Cherry-pick botu, isteği işler ve commit'lerin cherry-pick için uygun olup olmadığını bildirir. Commit'ler cherry-pick için uygunsa(yani commit'i cherry-pick ederken birleştirme çakışması yoksa) bot yeni bir pull isteği oluşturur. Pull isteği Bazel ekibinin bir üyesi tarafından onaylandığında commit'ler cherry-pick edilir ve yayın dalıyla birleştirilir. Tamamlanmış bir cherry-pick isteğinin görsel örneği için bu örneğe bakın.

5. Yayınlanmayı engelleyen sorunları belirleyin ve yayın dalında bulunan sorunları düzeltin.

   • Yayın 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 tüm gerilemeleri düzeltir.

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

   • Sürüm adayı bazel-discuss'ta duyurulur. Bazel ekibi, aday için topluluk tarafından gönderilen hata raporlarını izler.
   • Yeni yayın 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 yayın dalına yeni özellikler eklenemez. Değişiklik aktarımı yalnızca kritik düzeltmelerle sınırlıdır. Değişiklik aktarımı gerekirse talep eden kişi şu soruları yanıtlamalıdır: Bu değişiklik neden kritik öneme sahip ve ne gibi avantajlar sunuyor? Bu değişikliğin regresyona 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.
   • Yayın yalnızca sonraki günün iş günü olduğu günlerde gönderilir.
   • Yeni sürüm bazel-discuss'ta duyurulur. Bazel ekibi, yeni sürümle ilgili topluluk tarafından gönderilen hata raporlarını izler ve ele alır.

Regresyonları bildirme

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. Suçlu commit'i ikiye bölmek için Bazelisk'i kullanabilir ve bu bilgileri hata raporuna ekleyebilirsiniz.

Örneğin, derlemeniz Bazel 6.1.0 ile başarılı olurken 6.2.0'ın ikinci sürüm 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 gerekirse derleme durumunu sıfırlamak için ilgili Bazel komutlarını çalıştırmak üzere BAZELISK_SHUTDOWN veya BAZELISK_CLEAN ortam değişkenini ayarlayabilirsiniz. Daha fazla bilgi için Bazelisk bisect özelliği ile ilgili dokümanlara göz atın.

Bisect özelliğini kullanmak için Bazelisk'i en yeni 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.