PHP 8.6 yolda: dilin istikrarlı evrimi
PHP 8.6 sürümü çıkmadan önce: yıllık sürüm temposunun öngörülebilirliği ve olgun bir dilde 'sıkıcı' sürümlerin neden iyi haber olduğu.
Birkaç hafta sonra PHP 8.6 çıkacak — sürüm takvimine göre 19 Kasım 2026’da. Bu yazıyı, her yıl olduğu gibi, sürüm daha yayımlanmadan — RFC’lere ve sürüm adayı (RC) paketine bakarak — yazıyorum. Yeni özelliklerin tam listesini vermeyeceğim; çünkü bu yazının asıl konusu tek bir sürüm değil, PHP’nin yıllardır sürdürdüğü istikrarlı evrim.
Öngörülebilir bir tempo
PHP, 2020’den bu yana her yıl bir minör sürüm yayımlıyor. Tarih tek bir istisna dışında — 8.2, 8 Aralık 2022’de çıkmıştı — hep kasım oldu; son üç sürüm 20-23 Kasım aralığına oturdu. Bu düzenliliğin değerini yıllar geçtikçe daha çok anlıyorum. Bir sürümün ne zaman geleceğini bilmek, planlamayı mümkün kılıyor: ekipler yükseltmeyi takvimlerine koyabiliyor, kütüphane bakımcıları hazırlanabiliyor, kimse sürpriz yaşamıyor.
Heyecan verici olmayan ama güvenilir olan bir tempo — olgun bir teknolojinin işareti budur. “Bu yıl ne çıkacak acaba” diye merakla beklediğiniz bir dil, aynı zamanda üzerine on yıllık bir proje kurmakta tereddüt edeceğiniz bir dildir.
Sürüm çıkmadan ne yapıyorum
Her sürüm öncesi düzenim aynı. RFC listesini okuyup kabul edilenlere bakıyorum. RC paketini, kullandığım bir projenin testlerini onunla çalıştıracak kadar deniyorum. Kullanımdan kaldırılan (deprecated) özelliklere özellikle dikkat ediyorum.
Bu takvimin, sürüm gününü sıkıcı kılan bir ayrıntısı var: özellik listesi eylülde donuyor. 8.6 için hard feature freeze 22 Eylül 2026’ydı; o tarihten sonra sürüme yeni özellik girmiyor, yalnızca hata düzeltmesi giriyor. Yani kasımda öğrendiğimiz bir şey yok — kasımda yalnızca eylülde kesinleşmiş olan yayımlanıyor.
Bu yılın listesi de tanıdık kalıpta. Gözle görülür tek sözdizimi eklemesi partial function application (PFA): RFC 33 kabul / 0 ret ile geçti, durumu “Implemented”. Gerisi temizlik — 8.6 deprecation listesi kalabalık; örneğin finally bloğundan return etmek artık kullanımdan kaldırma uyarısı veriyor (39 kabul / 3 ret).
Yeni bir sürümü “çıkar çıkmaz” değerlendirmenin sırrı, onu çıkmadan önce takip etmiş olmak. Sürüm günü sürpriz yaşıyorsanız, geç kalmışsınız demektir.
Yeni özellikler için acele etmiyorum
Bir dil sürümü çıkar çıkmaz, herkes yeni özellikleri koda sokmaya hevesleniyor. Ben artık beklemeyi tercih ediyorum.
Bir özelliği, gerçek bir problemi çözdüğünü gördüğümde kullanıyorum — yeni olduğu için değil. Yeni sözdizimi her zaman daha iyi kod demek değil; bazen yalnızca daha yeni kod demek. PHP’nin son yıllardaki eklemeleri — tip sistemindeki olgunlaşma, değişmezliğe verilen destek — kodumu gerçekten değiştirdi; ama bunları benimsemem aylar, bazen bir yıl aldı. Acele etmemek bir kayıp değil; bir filtre.
Yükseltmeyi nasıl planlıyorum
Yeni bir minör sürümü benimseme biçimim de yıllar içinde oturdu. Sürüm çıkar çıkmaz onu hemen production’a taşımıyorum; önce bir bekleme dönemi tanıyorum.
İlk adım, kullandığım kütüphanelerin yeni sürümle uyumlu hâle gelmesini beklemek. Bir dil sürümü çıktığında ekosistemin tamamı aynı gün hazır olmuyor; birkaç hafta, bazen birkaç ay geçiyor. Erken davranıp uyumsuz bir bağımlılıkla boğuşmak, kazandırdığından çok zaman kaybettiriyor.
İkinci adım, geçişi küçük projelerden başlatmak. Önce kişisel ya da düşük riskli bir projeyi yeni sürüme alıyorum; orada her şey yolundaysa ve testler yeşilse, daha büyük projelere geçiyorum. Bu sıralama, olası sürprizleri en ucuz yerde keşfetmemi sağlıyor.
Üçüncü adım, kullanımdan kaldırılan özellikleri temizlemek. Yeni özellikleri eklemek heyecan verici kısım; ama asıl iş, eskiyen özellikleri zamanında çıkarmaktır. Bir kullanımdan kaldırma uyarısını görmezden gelmek, onu bir sonraki ana sürümde gerçek bir hataya dönüştürmek demektir. PHP 9.0 için duyurulmuş bir takvim yok; ama uyarı biriktirmenin faturasını o gün ödersiniz.
Özet
PHP 8.6’nın içeriği eylülde donduruldu; listeyi biliyorum. Bilmediğim, bu özelliklerin kendi kodumda ne kadar yer tutacağı — onu ancak sürümü gerçek bir projede aylarca çalıştırdıktan sonra söyleyebilirim. Ama bir şeyi şimdiden biliyorum: PFA gibi gözle görülür bir ekleme olsa da bu, öncekiler gibi, dili dramatik biçimde değiştirmeyen, onu bir adım daha olgunlaştıran bir sürüm. Uzun ömürlü bir dilde aradığım tam olarak bu — gösteri değil, süreklilik.
Bu yazının arkasındaki araştırmalar
PHP ekosistemi yeni sürümü beklemiyor — ama desteklediğini de söylemiyor
Bir PHP sürümü çıktıktan sonra en çok kurulan 500 Composer paketi onu desteklediğini ne zaman beyan ediyor, ve o beyan ne kadar bilgi taşıyor?
Bulgu
Kurulumların %56,4'ü üst sınırı hiç yazmayan bir kısıtla geliyor — symfony/console bugün >=8.4.1 diyor, yani PHP 12'yi de desteklediğini iddia ediyor. Üst sınır yazan 280 paketin 247'si taahhüdünü sürüm daha doğmadan vermiş: guzzlehttp/guzzle 8.4'ü Ekim 2020'de, dört yıl önceden kapsamış. Geriye gerçekten bekleyen 33 paket kalıyor, medyanları 325 gün. Ham sayılar sürümden sürüme düşüp 'ekosistem hızlanıyor' diye okunuyor; eşit gözlem penceresinde bakınca trend tersine dönüyor (238 → 215 → 325 gün).
71 gün önce doğrulandı
Bu konudaki deneyler
30'u aşkın PHP paketi hem tek başına hem birlikte kullanılabilir kaldı; Lab kaydı kapandı, paketler bakımda. Nasıl yapıldığının yapım notları.
Şu an ne yapıyor
30'u aşkın paketlik bir PHP kütüphane ailesi: Router, Database, Cache, Mailer, Socket ve diğerleri hem tek başına hem birlikte çalışıyor, hepsi Composer/Packagist üzerinden MIT lisansıyla dağıtılıyor. Framework'e bağlanmadan parça kullanmak isteyen PHP geliştiricisi bugün kurabilir.
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.