Upgrade Envanteri: Sürüm Numarası Değil, Katman Zinciri

“PHP 8.1’deyiz” bir envanter değil, altı katmandan birinin adıdır.

Cümle durum raporu gibi duyulur, çünkü tek bir sayı sorunun cevabını verir gibi görünür. Vermez. O sayı runtime’ın sürümü. Onun çevresinde, her biri kendi sürümüne ve kendi destek takvimine sahip beş katman daha var: extension’lar, framework, paketler, container imajı ve CI runner’ı. Hangi upgrade’in gerektiğini bu altısının toplamı söyler, birinin adı değil.

Sürüm numarasıyla yönetilen sistemde kilit ancak bir şey kırılınca görünür: build düşer, composer update bir paketi reddeder, imaj beklediğiniz PHP’yi getirmez. Soru o gün “ne zaman upgrade edelim”den “neden edemiyoruz”a döner. Cevap envanterde yazılıdır; envanter çıkarılmadıysa ilk kez o gün okunur.

Kilit çoğu zaman adını hiç yazmadığınız katmandadır: Bölüm 0’daki 7.1 kilidi runtime’da değil, paket katmanındaydı.

Altı katman, tek zincir

Paket o kilidi tek bir satırla koyar: composer.json’daki require.php, runtime’ın hangi sürüme çıkabileceğini paketin yazarına bırakır.

{
  "require": {
    "php": "^8.1"
  }
}

Bu satır, o paketi kuran her projenin PHP sürümünü sınırlar. Dockerfile’daki bir satır da aynı işi bir katman aşağıda yapar:

FROM php:8.2-fpm-bookworm

FROM hem PHP sürümünü hem de altındaki işletim sistemi sürümünü sabitler. Zincir, bu iki satırın arasında kalan her şeyi kapsar:

1. Runtime. PHP’nin kendisi. Diğer beş katmanın tavanı ve tabanı buradan geçer.
2. Extension’lar. Runtime’a derlenmiş ya da sonradan yüklenmiş modüller. Sürümleri runtime’a bağlıdır; projenin hangilerini istediğini composer.json/composer.lock’taki ext-* girdileri (ya da composer check-platform-reqs) söyler, composer show --platform yalnız komutun koştuğu ortamda kurulu olanları listeler.

İki katman, iki kısıt: runtime hangi extension sürümlerinin çalışacağını belirler, extension’ın desteklemediği bir PHP’ye çıkamazsınız.

3. Framework. Laravel 12, PHP 8.2–8.5 ister. Framework runtime’ı yukarıdan ve aşağıdan sınırlar.
4. Paketler. Yukarıdaki require.php satırı. Her paketin kendi alt ve üst sınırı vardır; hepsinin kesişimi runtime’ınızın gidebileceği aralıktır.

Framework ile paketler arasındaki ilişki de iki yönlü: framework’ün major’ı hangi paket sürümlerinin kurulabileceğini seçer, paketlerden biri eski kalırsa framework’e çıkışı bloke eder.

5. Container imajı. FROM satırı. Sürümü bir etiket olarak yazılı olduğu için en kolay okunan, en kolay unutulan katmandır; imaj bir kez build edildi mi, içindeki PHP ve işletim sistemi kodunuz değişmese de yaşlanır.
6. CI runner. Testi koşan ve imajı build eden ortam. Kendi imajı, kendi sürümü, kendi emeklilik tarihi var.

Altına işletim sistemi çekirdeği ve veritabanı sunucusu da iner; ikisinin de kendi takvimi var. Onları listeye yedinci ve sekizinci satır olarak ekleyebilirsiniz, ama burada altı katmanla kalıyorum.

Zincirin işlevi şu: katmanlardan biri hareket edemiyorsa, onun kısıtladığı komşular da edemez. Upgrade’i durduran, çoğu zaman en üstteki ya da en alttaki değil, ortada bir yerde sessizce duran halkadır.

Tarihi en erken biten katman koyar

Her katmanın saati ayrı çalışır ve hiçbiri diğerini beklemez. Aşağıdaki tarihler resmi sayfalardan; her biri farklı bir katmanın.

• Runtime. php.net politikası 2+2: iki yıl aktif destek, iki yıl yalnız security. PHP 8.2’nin security desteği 31 Aralık 2026’da bitiyor.
• Framework. Laravel 12.x sürüm notlarına göre Laravel 12 için security fix’ler 24 Şubat 2027’ye kadar sürüyor. Aynı sayfa Laravel 12’nin PHP 8.2–8.5, Laravel 13’ün PHP 8.3–8.5 istediğini yazıyor.
• Container imajı. Debian 12’nin EOL tarihi 12 Temmuz 2026; LTS desteği 30 Haziran 2028’e kadar. Debian 13 ise 9 Ağustos 2025’te yayımlandı.
• CI runner. GitHub, ubuntu-20.04 runner imajının 15 Nisan 2025’te tamamen emekli edileceğini duyurdu.

Bu listeden çıkan kural basit: upgrade tarihini ortalama değil, en erken biten destek belirler. Burada o katman PHP 8.2: 31 Aralık 2026, Laravel 12’nin 24 Şubat 2027’sinden önce geliyor. Framework’ün desteği sürse bile runtime’ın desteği bitmiş olacak ve Laravel 13’e çıkmak zaten PHP 8.2’yi geride bırakmayı gerektiriyor.

EOL’ü abartmamak gerekiyor. Upstream desteğinin bitmesi, hiçbir düzeltmenin gelmeyeceği anlamına gelmez; Debian 12’nin LTS’ye geçmesi bunun örneği. Ama düzeltmenin gelip gelmeyeceği artık bir dağıtımın ya da satıcının takvimine bağlıdır ve onun neyi kapsadığını okumak sizin işinizdir. Envanter, bu ayrımı yazılı hâle getirir: bitiş tarihi sütununa upstream tarihini, yanına varsa dağıtımın uzatılmış tarihini yazın, ikisini tek hücrede karıştırmayın.

Runner satırı ayrıca durmayı hak ediyor. Öteki katmanlarda tarih bir uyarıdır, burada ise imaj emekli olduğunda runs-on değeri o imajı artık bulamaz; job’a runner atanmaz ve çoğu zaman hata bile vermeden kuyrukta bekler. Bu yüzden CI katmanı, envanterde en son akla gelen ama en erken pahalıya patlayabilen satırdır.

Envanter: altı satır, beş sütun

Şablon şu: katman, çalışan sürüm, nereden okunur, destek bitişi, neyi kilitliyor. Altı katman altı satır; ek katman eklerseniz satır ekleyin, sütun eklemeyin. Sütunların sırası da bir okuma sırası: önce sürümü, sonra onu nereden okuduğunuzu yazarsanız, tabloyu başkası da aynı kaynaklardan doğrulayabilir.

Aşağıdaki doldurulmuş hâl varsayımsal bir sistemin. Yalnız tarihleri doğruladığım sürümleri seçtim; paket satırı bilerek boş duruyor, çünkü o satır sizin lock dosyanızdan dolacak.

Üç satırın “nereden okunur” hücresi aynı dosyaya, composer.lock’a gidiyor. Bu iyi haber: envanterin yarısı elinizdeki dosyalarda yazılı. Kötü haber ise kalan yarının, imajın ve runner’ın, bir lock dosyası olmadığı için çoğu zaman hiçbir yerde toplu yazılmaması.

“Bilinmiyor” geçerli bir cevap. Boş hücre ile “bilinmiyor” arasındaki fark, ikincisinin bir iş olarak kuyruğa girmesi.

Tablonun son adımı, destek bitişi sütununda en erken tarihi işaretlemek. Örnekte iki aday var: Debian 12’nin 12 Temmuz 2026’sı ve PHP 8.2’nin 31 Aralık 2026’sı. İlki imajın işletim sistemi katmanı için LTS ile 2028’e uzuyor, ikincisi runtime için uzamıyor. Hangi tarihi esas alacağınız (EOL mi, LTS mi) bir karardır; envanter ikisini de yazar, seçmez.

Bu çerçevenin sınırı

Envanter karar vermez, karar matrisine girdi üretir. Altı satırı doldurmak “hemen upgrade edin” demek değil; neyin, hangi tarihte, neyi kilitlediğini görünür kılmak.

Hangi sistemde hangi riskle, hangi sırayla ilerleyeceğiniz karar matrisinin işi: serinin Bölüm 3’ü. Hedef sürümü nasıl seçeceğiniz Bölüm 4’te, upgrade öncesi ön koşullar ve test Bölüm 5’te.

Bir de şu var: destek bitiş tarihi, sizin riskiniz değil, sağlayıcının takvimi. Aynı tarih bir iç araçta kuyruğa girer, ödeme akışında takvime. Tarih bir üst sınırdır, aciliyet değil. Hangi sinyalin zorunlu olduğunu Bölüm 1 ayırmıştı; bu bölüm o sinyallerin geldiği katmanları listeledi.

“PHP 8.1’deyiz” cümlesine dönelim

Cümle yanlış değil, eksik. Altı katmandan birini söylüyor ve kilidin çoğu zaman o katmanda olmadığını gizliyor.

Envanter bunu iki hamlede düzeltir: her katman için çalışan sürümü yazarsınız, sonra destek bitişlerini yan yana koyup en erkenini işaretlersiniz. O tarih, upgrade planının geri sayımını başlatan tarihtir; geri kalan beş satır, o sayımın neyle çarpışacağını gösterir.

Sonraki bölümlerde bu girdiyi kullanacağız: karar matrisi Bölüm 3’te, hedef sürüm Bölüm 4’te, ön koşullar Bölüm 5’te.

Bir sisteminizi seçin; altı katmanın her biri için çalışan sürümü ve destek bitiş tarihini tek satıra yazın, en erken tarihi işaretleyin.