Laravel Sürüm Takvimi 2026: 11 Bitti, Sıra Hangi Yükseltmede?

Uygulamanız Laravel 11'deyse desteği bitmiş bir sürümde çalışıyor. Framework'ün yayımlanmış politikası her ana sürüme 18 ay hata düzeltmesi ve 2 yıl güvenlik yaması veriyor; bu takvime göre Laravel 11 12 Mart 2026'da yaşam döngüsünü tamamladı. Laravel 12 ise 13 Ağustos 2026'da hata düzeltmelerini bıraktı ve 24 Şubat 2027'ye kadar yalnızca güvenlik penceresinde. Güncel ana sürüm Laravel 13 (17 Mart 2026).

Aşağıda destek tablosu, yükseltme sırası ve Türkiye'deki tipik Laravel projelerinde yükseltmeyi asıl geciktiren şey var.

Destek tablosu ve uygulamanızın bu tablodaki yeri

Tablodan çıkan tek cümle şu: bugün güvenlik yaması alan iki sürüm var, 12 ve 13. Bunların dışındaysanız, bulunan bir açık için kimse size yama göndermeyecek.

Asıl kısıt Laravel değil, PHP sürümünüz

Laravel 13 minimum PHP 8.3 istiyor. PHP'nin kendi takvimi (bkz. php.net, Supported Versions) şöyle:

• PHP 8.2: aktif destek 31.12.2024'te bitti, güvenlik desteği 31.12.2026'da bitiyor.
• PHP 8.3: aktif destek 31.12.2025'te bitti, güvenlik desteği 31.12.2027'ye kadar.
• PHP 8.4: aktif destek 31.12.2026'ya, güvenlik 31.12.2028'e kadar.
• PHP 8.5: aktif destek 31.12.2027'ye, güvenlik 31.12.2029'a kadar.

Yani PHP 8.2'de kalmayı planlıyorsanız, elinizde 31 Aralık 2026'ya kadar süre var ve o tarihten sonra Laravel sürümünüz ne olursa olsun yorumlayıcı tarafında yama almıyorsunuz. Türkiye'de paylaşımlı hosting veya eski bir cPanel sunucusunda duran projelerde gerçek engel buradan çıkıyor: Laravel'i yükseltmek kolay, sunucudaki PHP'yi yükseltmek ise tedarikçi bağımlı.

Yükseltme planını Laravel sürümünden değil PHP sürümünden başlatın. Önce PHP 8.3'e (tercihen 8.4'e) çıkın ve uygulamanın mevcut Laravel sürümüyle bu PHP'de çalıştığını doğrulayın. Ancak ondan sonra framework sürümünü çıkın. İkisini aynı gün yaparsanız, çıkan hatanın hangisinden geldiğini ayırt edemezsiniz.

Laravel 13'te kod değiştirmenizi gerektirmeyen şeyler

Yayın notu bu sürümde kırıcı değişiklikleri en aza indirmeye odaklanıldığını söylüyor: yıl boyunca uygulamaları bozmayan iyileştirmeler yayımlanmış ve 13'e geçiş efor olarak görece küçük tutulmuş. Çoğu uygulama kod tarafında fazla bir şey değiştirmeden geçebiliyor.

İşinizi doğrudan kolaylaştıracak birkaç ekleme:

• Kuyruk yönlendirme. Queue::route(ProcessPodcast::class, connection: 'redis', queue: 'podcasts') ile hangi işin hangi bağlantı ve kuyrukta çalışacağını merkezî bir yerde tanımlıyorsunuz. Her job sınıfının içine dağılmış kuyruk adlarını toplamak için iyi bir fırsat.
• Attribute tabanlı yapılandırma. Controller tarafında #[Middleware] ve #[Authorize], kuyruk tarafında #[Tries], #[Backoff], #[Timeout], #[FailOnTimeout].
• JSON:API kaynakları. Kaynak nesnesi serileştirme, ilişki dahil etme, sparse fieldset ve JSON:API uyumlu başlıklar birinci sınıf hâle geldi. Kendi elle yazdığınız JSON:API katmanınız varsa artık silinebilir.
• Cache::touch(...). Bir cache öğesinin TTL'ini, değeri okuyup yeniden yazmadan uzatıyor.
• Semantik/vektör arama. Sorgu üreticisinde whereVectorSimilarTo('embedding', 'Best wineries in Napa Valley') ile PostgreSQL + pgvector üzerinde benzerlik araması.

Güvenlik tarafında bir davranış değişikliği var: istek sahteciliği koruması PreventRequestForgery adıyla formalize edildi ve token tabanlı CSRF korumasıyla uyumluluğu korurken kaynağa (origin) duyarlı istek doğrulaması ekledi. Ters proxy arkasında çalışan ve X-Forwarded-* başlıklarını doğru iletmeyen kurulumlarda ilk kırılacak yer burası; yükseltme sonrası ilk kontrol edeceğiniz şey POST formlarınız olsun.

Yükseltme sırası

1. Bağımlılıkları dondurun ve testleri görün. Testiniz yoksa yükseltmeden önce en kritik 10 akışa smoke test yazın. Yükseltmenin maliyeti test yazmak değil, testsiz yükseltmenin geri dönüşü.
2. PHP'yi çıkın. Önce yerel ve hazırlık ortamında, sonra üretimde. Deprecation uyarılarını log'da açık tutun.
3. Ara sürümleri atlamayın. 10 → 13 tek adımda yapılmaz; 11 ve 12 üzerinden geçin, her adımda testleri koşturun.
4. Üçüncü parti paketleri sayın. Yükseltmeyi tıkayan şey neredeyse her zaman bakımı durmuş bir paket olur. Yükseltmeye başlamadan composer outdated --direct çıktısını alın ve her paketin hedef sürümü destekleyip desteklemediğini tek tek işaretleyin.
5. Ters proxy ve oturum yapılandırmasını doğrulayın. Origin duyarlı doğrulama, sağlıklı görünen kurulumlarda bile 419 üretebiliyor.

Şu durumdaysanız şunu yapın

Son satır Türkiye'deki projelerde en sık karşılaşılan tıkanma. Uygulamanın PHP sürümünü hosting sağlayıcısı belirliyorsa, güvenlik takviminiz de onun elinde demektir. Bu, yükseltme değil taşıma işidir ve kapsamı ayrı planlanmalıdır.

Bugün bakılacak tek dosya

composer.json dosyanızı açın ve "laravel/framework" kısıtınıza bakın. ^11.0 görüyorsanız desteksiz bir sürümdesiniz ve bu, bir sonraki güvenlik denetiminde bulgu olarak çıkacak. ^12.0 görüyorsanız 24 Şubat 2027'ye kadar vaktiniz var, ama hata düzeltmesi almıyorsunuz.

Dağıtım ve sürümleme tarafı için Docker ile üretime dağıtım, mimari kararlar için mikroservis mi monolit mi, veritabanı seçimi için PostgreSQL ve MySQL karşılaştırması yazılarına bakabilirsiniz. Laravel tarafındaki çalışma biçimimiz Laravel sayfasında; mevcut bir uygulamanın yükseltme kapsamını konuşmak için iletişim sayfasından yazabilir, kaba bir bant için proje fiyat hesaplama aracını kullanabilirsiniz.

Destek tarihleri ve Laravel 13 özellikleri 25 Eylül 2026'da laravel.com/docs/releases adresindeki yayın notlarından, PHP destek takvimi php.net/supported-versions.php adresinden doğrulanmıştır. Kod parçaları resmî yayın notundaki örneklerdir.