# Upgrade Tetikleyicileri: Zorunlu, Kilitleyen, Fırsat

> Dependabot PR'ı, EOL duyurusu ve CVE bülteni aynı kuyruğa düşer ama aynı aciliyette değildir. Sinyalleri üç türe ayırıp her birine tepki süresi bağlamak.

- Tür: Notlar
- Yayın: 2026-10-25
- Etiketler: dependencies, decisions, security, production
- Dizi: Production'da Upgrade
- Okuma süresi: 5 dk okuma
- Kaynak: https://muhammetsafak.com/tr/muhendislik/notlar/upgrade-tetikleyicileri/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
> **Kısaca:** Dependabot PR'ı, EOL duyurusu, deprecation uyarısı ve CVE bülteni aynı kuyruğa düşer ama aynı aciliyette değildir. EOL ve etkilendiğiniz CVE zorunludur, bağımlılık kilidi ve deprecation kilitleyendir, özellik ve performans fırsattır. Her türe bir tepki süresi yazmak, hatırlatmaya koşmayı ve kilide geç kalmayı önler.

Dependabot'un açtığı PR'ların çoğu zorunluluk değil, hatırlatmadır.

Kuyrukta dört tür sinyal birbirine karışıyor: Dependabot PR'ları, deprecation uyarıları, EOL duyuruları ve CVE bültenleri. Her biri farklı bir kaynaktan, farklı bir nedenle doğuyor ama hepsi aynı listeye, aynı tonda düşüyor. Ekran aynı görünüyor, iş aynı büyüklükte değil.

Zorunlu olan başka yerden gelir: bir EOL tarihinden, bir CVE'den ya da sizi eski sürüme kilitleyen bir bağımlılıktan. Üçüne aynı tepkiyi veren ekip ya geç kalır ya da boşuna koşar.

## Kuyruğa iki ayrı saat düşer

Bir PR'ın ne kadar acil olduğu başlığında yazmaz; onu hangi saatin açtığında yazar: biri bir advisory'ye, öteki `dependabot.yml`'deki takvime bağlıdır.

GitHub'ın belgelerine göre security updates açıldığında, güvenlik açığı olan bir bağımlılık bulunduğunda yeni PR açılır. Version updates ise yeni bir sürüm çıktığında açılır ve `dependabot.yml`'de tanımladığınız sıklıkla çalışır. Birincisini dış dünyada olan bir şey tetikler, ikincisini sizin yazdığınız takvim.

Bir ayrıntı daha: `cooldown` ayarı yalnız version updates için PR açılışını geciktirir; security updates'e uygulanmaz. Yani PR gürültüsünü kısmak için kurduğunuz ayar, güvenlik PR'ını susturmaz.

Pratik sonuç şu: haftalık takvimle gelen version update PR'ı, bir advisory'den doğan PR ile aynı kuyrukta durur ama aynı saatin işi değildir. Birini bu hafta, ötekini bu çeyrek ele alabilirsiniz.

Bir PR'ı açmadan önce iki şeye bakın: kim açtı, hangi etiketle geldi. Security update ise soru artık sürüm farkı değil, etkilenip etkilenmediğiniz. Version update ise soru, o sürümün bir şeyi çözüp çözmediği. İkincisinin cevabı çoğu zaman "hayır, yeni bir sürüm çıkmış, hepsi bu" olacak.

## EOL bir tarih, CVE bir olay

EOL önceden bilinir. [php.net](https://www.php.net/supported-versions.php) her dalın security desteğinin bitiş tarihini yayımlıyor ve politika basit: yayından itibaren iki yıl aktif destek, ardından iki yıl yalnız güvenlik düzeltmesi. PHP 8.2'nin security desteği **31 Aralık 2026**'da bitiyor. Bu yazının yayın tarihinden yaklaşık 9,5 hafta sonra.

Framework katmanı da kendi saatini tutuyor. Laravel'in [12.x sürüm notları](https://laravel.com/docs/12.x/releases) şöyle diyor: bug fix'ler 18 ay, security fix'ler 2 yıl sağlanır. Laravel 12 için bu, bug fix'lerin 13 Ağustos 2026'da bittiği, security fix'lerin 24 Şubat 2027'ye kadar sürdüğü anlamına geliyor. Yani bu yazının yayımlandığı gün Laravel 12 çalıştıran bir ekip, bug fix desteğini çoktan kaybetmiş, security desteğini henüz kaybetmemiş durumda.

CVE ise takvime uymaz. Salı sabahı çıkabilir, hangi sürümü çalıştırdığınıza bakmaz.

EOL'ün sonrasını da abartmamak gerekiyor. Upstream desteğinin bitmesi, düzeltme gelmeyeceği anlamına gelmez; gelmesi sizin kontrolünüzden çıkar. Ubuntu'nun [USN-6305-2](https://ubuntu.com/security/notices/USN-6305-2) bülteni bunun örneği: PHP 7.4'ün upstream desteği Kasım 2022'de bitmişti; 27 Şubat 2024'te Ubuntu, CVE-2023-3823 ve CVE-2023-3824 için PHP paketlerine düzeltme yayımladı. 20.04'teki `php7.4` bunu standart depodan aldı; 18.04'teki `php7.2` ve 16.04'teki `php7.0` için ESM ve Ubuntu Pro gerekti.

Bu bir çıkış yolu olabilir. Ama bedeli bir satıcıya bağlı kalmak, düzeltmenin hangi paketle ve hangi hızla geleceğini onun takvimine bırakmak.

EOL tarihinin değeri öngörülebilir olmasında. Tarihi geriye doğru hesaplayabilirsiniz: bitiş gününden önce production'da olmak istediğiniz sınırı koyun, oradan staging'e, oradan test işine geri sayın. Aşağıdaki önerimi 8.2'ye uygularsam sınır 30 Eylül 2026 olurdu. Bu yazıyı okurken hâlâ 8.2 çalıştırıyorsanız o sınır geçmiş durumda; bu bir suçlama değil, planı bugün yazmanın nedeni.

## Kilitleyen tetikleyici görünmez

Kilitleyen tetikleyici ne bir tarih taşır ne bir bülten. Bir paket eski runtime'ı desteklemeyi bıraktığında yeni sürümü kurulamaz hâle gelir, kimse de size haber vermez.

PHP 7.1 vakasında tetikleyici EOL değildi, bağımlılık kilidiydi; ayrıntısı [Upgrade'i Ertelemenin Maliyeti](/tr/muhendislik/denemeler/upgrade-ertelemenin-maliyeti/) yazısında.

Kilidin bir EOL gibi tarihi olmadığı için ölçmeniz gerekir: bekleyen paket güncellemelerinden kaçı, runtime sürümünüz yüzünden kurulamıyor? Sıfırdan büyük her sayı, bir kapının kapandığını gösterir.

Kilit sessiz büyür. Eski runtime'da her şey çalışmaya devam ettiği için hiçbir alarm üretmez; ilk görünür sinyal, güncellemek istediğiniz paketin kurulamadığı gündür. O gün tür artık fırsat değil, kilitleyendir ve çıkışın tek parça olması muhtemeldir.

## Üç tür, üç tepki süresi

Sinyalleri üç türe ayırıyorum:

- **Zorunlu:** dışarıdan gelen ve tarihi ya da riski sizin tercihinizden bağımsız olan sinyal (EOL, etkilendiğiniz CVE).
- **Kilitleyen:** bugün bir şey bozmayan ama yarın seçeneğinizi daraltan sinyal.
- **Fırsat:** yapmazsanız hiçbir şeyin bozulmadığı, yaparsanız kazanç sağlayan sinyal.

Aşağıdaki tepki süreleri benim önerim. Sektör standardı değil; kendi ekibinizin kapasitesine göre kaydırın, ama bir süre yazın. Süresi olmayan sinyal kuyrukta bekler, kuyrukta bekleyen sinyal de sonunda "acil" olarak geri döner.

| Sinyal | Tür | Tepki süresi (önerim) |
|---|---|---|
| Etkilendiğiniz bir CVE | Zorunlu | Triage aynı iş günü, yama günler içinde |
| Etkilenmediğiniz bir CVE | Fırsat | Normal döngü; etkilenmediğinizin kaydı tutulur |
| EOL tarihi | Zorunlu | Tarih takvime girer; production'da bitiş tarihinden en az 3 ay önce |
| Bağımlılık kilidi | Kilitleyen | Bir sonraki çeyrek planına girer |
| Deprecation uyarısı | Kilitleyen | Bir sonraki major'dan önce |
| Özellik ya da performans | Fırsat | Backlog; ölçülmüş bir kazanç yoksa tarih yok |

Tablonun iki satırı ayrıca durmayı hak ediyor. Önce CVE: aynı bülten, sizin kullandığınız kod yoluna dokunuyorsa zorunlu, dokunmuyorsa fırsattır. Aciliyeti bültenin başlığı değil, sizin sisteminiz belirler. Bunu belirlemek için iki soru yeter: etkilenen bileşeni kullanıyor muyum, etkilenen kod yoluna dışarıdan erişilebiliyor mu? İkisine de "evet" diyorsanız tablodaki ilk satırdasınız; düzeltme henüz sizin sürüm dalınıza gelmediyse bu, süreyi uzatmaz, işi yamadan geçici önleme çevirir. Cevaplardan biri "hayır" ise bunu kayda geçirin; kayıt, bir ay sonra aynı bülteni yeniden tartışmanızı engeller. Sonra performans: "yeni sürüm daha hızlı" cümlesi bir fırsattır, bir zorunluluk değil. Ölçmeden o cümleyle takvim açmayın.

Kilitleyen satırlarda süre neden gün değil çeyrek? Çünkü kilit bugün bir şey bozmuyor; ama her çeyrek bir paket daha eski runtime'ı bırakırsa çıkışın maliyeti büyür. Çeyrek, bunu fark etmek ve bir sonraki planlamaya yazmak için yeterince kısa bir süre.


> **Tan:** Türü ve tepki süresini sinyalin durduğu yere yazmak, tabloyu ayrı bir sayfada tutmaktan daha çok işe yarar: issue etiketi ya da PR açıklamasında tek satır yeter. Kuyruğa bakan kişi kararı listeden okur, wiki'yi açmak zorunda kalmaz. "Etkilenmiyoruz" kaydı da aynı yerde durur; bülten bir ay sonra yeniden düştüğünde cevap zaten oradadır.


## Bu çerçevenin sınırı

Bu sınıflandırma karar matrisinin yerini tutmaz. Tür, aciliyetin üst sınırını söyler; hangi sistemde, hangi riskle, hangi sırayla yapılacağını söylemez.

Aynı CVE bir iç araçta fırsat, ödeme akışında zorunlu olabilir. O ayrımı sistemin kritikliği yapar. Karar matrisi serinin Bölüm 3'ünde.

Tür ayrıca sabit değildir. Bir fırsat, ertelendikçe kilitleyene döner; bir kilit, EOL tarihi yaklaştıkça zorunluya. Sınıflandırmayı bir kez yapıp kuyruğa gömmeyin, her planlama turunda yeniden bakın.

## Kuyruğa geri dön

Başa dönelim: o Dependabot PR'ı. Hangi saat açtı onu? Bir advisory mi, takvim mi? Bir kilidi mi çözüyor, yoksa yalnızca yeni bir sürümün çıktığını mı söylüyor? Üç soru, çoğu PR'ı fırsat ya da hatırlatma sınıfına yollar ve geriye gerçekten bu hafta bakılacak birkaç iş kalır.

Sınıflandırmanın amacı daha az upgrade yapmak değil; doğru olanı doğru zamanda yapmak. Hatırlatmayı zorunluluk gibi karşılayan ekip boşuna koşar, kilidi hatırlatma sanan ekip geç kalır. İkisinin de bedeli aynı kuyruktan çıkar.

Burada sinyalleri sınıflandırdım. Hangi sistemleri, hangi katmanlarda takip edeceğinizi serinin Bölüm 2'sinde, hedef sürümü nasıl seçeceğinizi Bölüm 4'te, upgrade etmemenin ne zaman doğru karar olduğunu Bölüm 8'de ele alacağım.

Kuyruğunuzdaki son 10 upgrade sinyalini zorunlu, kilitleyen ve fırsat diye ayırın; her birine bir tepki süresi yazın.

## Kaynaklar

- [Supported Versions](https://www.php.net/supported-versions.php) — PHP
- [Laravel 12.x Release Notes](https://laravel.com/docs/12.x/releases) — Laravel
- [Optimizing PR creation for version updates](https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates) — GitHub
- [USN-6305-2: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-6305-2) — Canonical