Laravel 6 ve LTS'in anlamı: sürüm stratejisi

Eylül 2019’da yayınlanması beklenen Laravel 6, LTS etiketi taşıyacak. Bu haberi duyduğumda ilk tepkim “yeni özellikler ne?” oldu; ama bir süre düşününce asıl sorunun başka olduğunu fark ettim: bir framework’ün sürümleme stratejisi proje kararlarını nasıl etkiliyor?

Laravel 5.x serisinde sürümler altı ayda bir geliyordu. Her sürümde yeni özellikler, ama aynı zamanda breaking change’ler. Bir projede 5.4 kullanıyorsanız ve 5.8’e geçmek istiyorsanız bu önemsiz bir iş değil. LTS sürümleri farklı: 6.x için iki yıl hata düzeltmesi, üç yıl güvenlik güncellemesi taahhüt ediliyor.

LTS ne kazandırıyor?

Kararlılık garantisi. Bir LTS sürümü, framework’ün o major versiyonunun API’sinin değişmeyeceği anlamına geliyor. Proje ekibi “hangi sürümde kalıyoruz?” sorusunu birkaç yıl sormak zorunda kalmıyor.

Kurumsal projelerde ikna kolaylığı. Büyük organizasyonlarda bir teknolojiyi benimsemek, üst katmanlara “kaç yıl desteklenecek?” sorusunu yanıtlamayı gerektiriyor. “Aylık sürüm” ritmi bu soruyu yanıtlamıyor. LTS etiketi, somut bir yanıt sunuyor.

Bakım maliyeti. Framework güncellemesi ciddi test ve adaptasyon süresi gerektiriyor. LTS projelerinde bu maliyet üç yıla yayılabiliyor.

Kaybedilen şey: hız

LTS’in bedeli var. Laravel’in geliştirme hızı yüksek ve her sürüm gerçekten faydalı şeyler getiriyor. LTS’te kalmak, gelen özellikleri hemen kullanamamak demek. Bu trade-off’u kabul etmek gerekiyor.

Ben bu denklemi şöyle kuruyorum: projenin ömrü ne kadar?

Altı ayda bir teslim edilip kapatılacak bir proje için LTS pek anlam taşımıyor — zaten bir veya iki sürüm içinde bitiyor. Ama üç, beş, on yıl boyunca bakımı yapılacak bir kurumsal uygulama için LTS çok daha mantıklı.

Semver ve semantic versioning

Laravel 6’nın sürüm numarasında başka bir değişiklik var: artık semantic versioning (semver) tam anlamıyla uygulanıyor. Daha önce 5.x’teki minor versiyonlar breaking change içerebiliyordu — bu standart semver davranışı değil.

Semver kuralı şu:

• Major sürüm (6 → 7): breaking change içerebilir.
• Minor sürüm (6.1 → 6.2): geriye dönük uyumlu yeni özellikler.
• Patch sürüm (6.1.1 → 6.1.2): geriye dönük uyumlu hata düzeltmeleri.

Bu değişiklik küçük görünüyor ama bağımlılık yönetimi açısından önemli. ^6.0 gibi bir kısıtlama artık gerçekten “6.x ailesi, breaking change olmaz” anlamına geliyor.

PHP versiyonu bağı

Laravel 6, PHP 7.2 minimum gereksinimiyle geliyor. PHP 5 desteği çoktan düşmüştü; 7.x ailesi artık standart. Bu da uzun vadeli düşündüğünüzde framework ve dil arasındaki minimum gereksinim kaldıraçlarını hesaba katmanız gerektiği anlamına geliyor.

Pratik karar: ne zaman LTS?

Benim için şu filtre işe yarıyor:

• Proje ömrü 2 yılın üzerindeyse → LTS ciddi bir seçenek.
• Ekipte framework güncellemelerini takip edecek bant genişliği yoksa → LTS.
• Her yeni özelliği hemen kullanmanız gerekiyorsa ya da aktif geliştirme devam ediyorsa → en güncel sürüm.

Framework’ün sürüm stratejisini düşünmek “yazılım mühendisliği değil idari detay” gibi gelebilir. Ama gerçek projelerde bu kararlar yıllarca hissediliyor. Bir projeyi bakımı zor bir sürüm borusuna kilitlemek de, gereksiz güncelleme yükü altında ezilmek de maliyetli.