# PHP 7.1'den 8.2'ye: Ertelenen Upgrade'in Asıl Faturası > Bakımını yaptığım bir PHP uygulamasında 7.1'den 8.2'ye geçiş 2023'te önerildi, 2024'te yapıldı. Faturanın en pahalı kalemi beklediğim yerde çıkmadı. - Yayın: 2026-10-18 - Kategori: Günlük - Etiketler: PHP, Refactoring - Okuma süresi: 3 dk okuma - Kaynak: https://muhammetsafak.com/tr/blog/php-7-1den-8-2ye-ertelenen-upgradein-faturasi/ - Dil: tr-TR - Yazar: Muhammet Şafak --- > **Kısaca:** 2023'te PHP 7.1'den 8.2'ye geçmeyi önerdim, cevap çalışıyor ne gerek var oldu. Geçiş 2024'te, onlarca breaking change ile tek seferde yapıldı. Listesi çıkan değişiklikler bütçeye sığdı; tek bir case'de ortaya çıkan ve aylara yayılan bug'lar sığmadı. Ertelenen upgrade'in en pahalı kalemi breaking change'ler değildi. Onların listesi çıkarılabiliyordu. Listesi çıkmayan, tek bir case'de ortaya çıkıp aylara yayılan bug'lar çıkarılamıyordu. Bakımını yaptığım bir PHP uygulamasında 2023'te PHP 7.1'den stabil 8.2'ye geçmeyi önerdim. Cevap kısaydı ve ertelendi; geçiş 2024'te yapıldı. 2026'dan bakınca faturayı kalem kalem yazabiliyorum. Aşağıdaki sıra, kalemlerin bana göründüğü sıra değil, geriye bakınca anladığım sıra. ## Öneri ve cevap Önerdiğim gün cevap şuydu: "Çalışıyor, ne gerek var?" Cevap yanlış değildi. Uygulama çalışıyordu ve o gün bozuk olduğunu gösterebileceğim hiçbir şey yoktu. Yine de öneriyi boş yere yapmamıştım. PHP 7.1'in desteği [PHP.net: Unsupported Branches](https://www.php.net/eol.php) sayfasına göre 1 Aralık 2019'da bitmişti; son sürüm 7.1.33'tü. Hedef olarak önerdiğim 8.2 ise 8 Aralık 2022'de çıkmıştı ve o gün için stabil bir seçimdi. O gün elimdeki en somut bilgi şuydu: geçiş 1–2 günlük bir işti. Küçük işler ertelenmeye en yatkın işlerdir. "Önce acil olanı bitirelim" cümlesi her takvimde yer bulur ve bu kez de buldu. ## Kilit sessizce kuruldu Bu arada bir şey oldu ve hiçbir alarm üretmedi: paketler eski PHP desteğini kesmeye başladı. Bir paket yeni sürümünde 7.1'i bırakıyordu, biz eski sürümde kalıyorduk. Sonra bir sonraki paket, ardından bir sonrakisi. Her biri tek başına ertelenebilir bir ayrıntıydı. Bir noktadan sonra güncellenebilecek paket kalmadı ve uygulama 7.1'e kilitlenmiş oldu. Bu mekanizmayı, bağımlılık kilidini ve ertelemenin neden "makul kararların toplamı" olduğunu sade.dev'de [Upgrade'i Ertelemenin Maliyeti](https://sade.dev/tr/journal/upgrade-ertelemenin-maliyeti/) yazısında ayrıca yazdım. Burada tekrarlamıyorum; yalnız bu vakanın uygulama tarafını anlatıyorum. O günlerde 1–2 günlük bir işin yanına bir de şu kalem eklenmişti: paket güncellemesi başına birkaç saat. İkisi de küçük görünüyordu. Küçük görünmesi, ertelemeyi kolaylaştıran şeydi. ## 2024: Tek seferde ödenen liste Geçişi 2024'te yaptık. Artık adım adım gidemiyorduk; 7.1'den 8.2'ye aradaki sürümleri tek tek geçmeden, bir seferde atlamak zorundaydık. Önüme onlarca breaking change ve deprecated öğe çıktı. Hepsi aynı anda çözülmek zorundaydı. 2023'te parçalara bölünebilecek iş, 2024'te bölünemeyen tek bir işe dönüşmüştü. Yine de bu kalemin bir iyi yanı vardı: görünüyordu. Hata mesajı hangi satırın eski sözdizimine yaslandığını gösteriyor, deprecated bildirimleri neyin kalktığını söylüyordu. Liste çıkarılıyor, tek tek kapatılıyor, bitiyordu. Uzun bir liste olduğunu söyleyebilirim ama bilinmeyen bir şey içermiyordu. Büyüklüğünü kabaca kestirir, takvime yerleştirirsiniz. Toplam süreyi ölçmedim; bu yüzden size bir gün ya da hafta sayısı veremiyorum. Elimdeki tek karşılaştırma 2023'teki 1–2 gün ile 2024'teki "onlarca değişiklik tek seferde". ## Listede olmayan kalem Asıl fatura geçişten sonra geldi. Bir kısım bug yalnız tek bir case'de ortaya çıkıyordu: sık tetiklenmeyen bir yol, belirli bir veri, belirli bir sıra. Böyle bir bug'ı önce fark etmeniz, sonra yeniden üretmeniz, sonra nedenini bulmanız gerekiyor. Her biri ayrı bir araştırma. Bir tanesi kapanıyor, başka bir case'de bir başkası çıkıyordu. Çözümleri aylara yayıldı. Bunu bütçeye yazamıyordum. Breaking change'in tahmini yapılabiliyordu, bug'ın yapılamıyordu. Bütçeyi birincisine göre kurarsanız ikincisi bütçenin dışında, takvimin içinde yaşanıyor. Bir şey daha vardı ve ben bunu geç fark ettim: onlarca değişikliği bir arada taşımak, her bug'ın kaynağını onlarca adaya çıkarıyordu. Bir bug'ın hangi değişiklikten geldiğini ayırmak ayrı bir iş oluyordu. Bu bir ölçüm değil, benim gözlemim. Karşı-sezgisel olan şu: ertelemeyi konuşurken hep breaking change listesini hesaplıyoruz. Bedel orada değil, uzun kuyrukta çıktı. > **Tan:** Bu vakada beni düşündüren, bilinmeyen için bütçeye hiçbir şey yazmamanın tarafsız bir tercih gibi görünmesi. Oysa o payı sıfır bırakmak da bir tahmin, üstelik elimizdeki en iyimser tahmin. ## Geriye bakınca Ben bu işi bugün tekrar yapsam üç şeyi farklı yapardım. İlki, 2023'teki öneriyi "gerekli" diye değil, "şimdi 1–2 gün, sonra tek seferde onlarca değişiklik" diye yazardım. "Çalışıyor" cümlesinin karşısına "hiçbir şey kazanmıyoruz" demek yetmiyor; karşılaştırmanın yönünü göstermek gerekiyor. İkincisi, her paket güncellemesinin kurulamadığı günü bir yere not ederdim. O gün, kilidin kurulduğunun en erken işaretiydi. Üçüncüsü, geçişten sonraki ilk aylar için bug kuyruğuna ayrı bir pay ayırırdım. Ne kadar? Bilmiyorum; ölçmedim ve tahmin etmek de istemiyorum. Ama sıfır olmadığını artık biliyorum. Bu vakanın ironik bir kapanışı da var. Hedef olarak önerdiğim 8.2'nin security desteği, [PHP.net: Supported Versions](https://www.php.net/supported-versions.php) sayfasına göre 31 Aralık 2026'da bitiyor. Yani vakanın hedefi bile kendi takvimine girdi. Bu vakadan çıkardığım şey basit: bir sonraki turun tarihini önceden yazmak. Upgrade etmemek de meşru bir karar olabilir; hangi durumlarda olduğunu sade.dev'deki seride ele alıyorum. Benim itirazım ertelemeye değil, ertelemenin bir karar olarak yazılmamasına. Bugün yapabileceğiniz tek şey şu: kendi sisteminizdeki runtime ve framework sürümlerinin destek bitiş tarihlerine bakın ve bir yere yazın. İki satır yeter: ne çalışıyor, desteği ne zaman bitiyor. ## Kaynaklar - [PHP.net: Supported Versions](https://www.php.net/supported-versions.php) - [PHP.net: Unsupported Branches](https://www.php.net/eol.php)