# PHP ekosistemi yeni sürümü beklemiyor — ama desteklediğini de söylemiyor

> Packagist'in en çok kurulan 500 paketinin bütün sürüm geçmişini tarayıp `require.php` kısıtlarını okudum. Aradığım gecikme sayısı çıkmadı; çıkan şey, o sayının neden aranamayacağı oldu.

- Tür: Tarama
- Soru: 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 %43,5'i ü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).
- Yöntem: Packagist'in popülerlik uçlarından en çok kurulan 500 paket alındı, her birinin bütün kararlı sürümleri `repo.packagist.org/p2` metadata ucundan çekildi ve her sürümün taşıdığı `require.php` kısıtı okundu. Kısıtlar el yazımı bir okuyucuyla çözülüyor: npm'in `semver`'i Composer'la aynı sözdizimini farklı okuyor (`~8.1` Composer'da `>=8.1 <9.0`, semver'de `>=8.1.0 <8.2.0`), o yüzden ödünç alınmadı; okuyucu çözemediği kısıtı yutmuyor, fırlatıyor ve koşu sayıyor (bu turda 0). Bir kaydın hangi kovaya düştüğü üç elemeden geçiyor: sürümden sonra doğan paketler dışarıda (beklemiş olamazlar), kısıtsız sürümler her PHP'yi kabul ediyor sayılıyor (Composer'ı engellemiyorlar), ve gecikme yalnız üst sınır yazan kısıtlarda ölçülüyor. Sürümler arası karşılaştırma en kısa gözlem penceresine (639 gün) kırpılıyor. Tarama deterministik: aynı gün tekrar koşulduğunda aynı sayıları veriyor.
- Metrikler: Üst sınırsız kısıtla gelen kurulum: %43,5 · Önceden taahhüt eden: 247 / 280 paket · Gerçekten bekleyenlerin medyanı: 325 gün · Eşit pencerede 8.2 → 8.4: 238 → 325 gün (+%37)
- Doğrulama tarihi: 2026-08-22
- Güven: Yüksek güven
- Durum: Yürürlükte
- Program: Dil & çalışma zamanı
- Ortam: Evren Packagist, kuruluma göre ilk 500 paket · Veri ucu packagist.org/explore/popular.json · repo.packagist.org/p2 · Sürüm süzgeci yalnız kararlı etiketler (dev/alpha/beta/RC hariç) · PHP çıkış tarihleri php.net/supported-versions (8.2: 2022-12-08 · 8.3: 2023-11-23 · 8.4: 2024-11-21) · Karşılaştırma penceresi 639 gün — en kısa gözlem süresi (8.4) · Okunamayan kısıt 0
- 3 kaynak: Packagist API (https://packagist.org/apidoc) · PHP: Supported Versions (https://www.php.net/supported-versions.php) · Composer — Versions and constraints (https://getcomposer.org/doc/articles/versions.md)
- Teknolojiler: PHP, Composer, Packagist
- Tekrarlamak için: node scan.mjs --top 500 --php 8.2,8.3,8.4
- Kaynak kodu: https://github.com/muhammetsafak/packagist-php-support
- Ham veri: https://github.com/muhammetsafak/packagist-php-support/blob/main/results/2026-08-22/php-support.json
- Ham veri lisansı: https://github.com/muhammetsafak/packagist-php-support/blob/main/LICENSE
- Yayın: 2026-08-22
- Kaynak: https://www.muhammetsafak.com.tr/research/php-surum-destegi-beyani/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
Sormak istediğim şey basitti: PHP 8.4 çıktıktan sonra ekosistem onu ne zaman
desteklemeye başladı? Her ekibin sorduğu soru bu — "ne zaman yükseltebilirim".
Cevabı `require.php` kısıtlarında aramak makul görünüyordu.

Aradığım sayı çıkmadı. Çıkan şey daha ilginç: **o sayının neden aranamayacağı.**

## İlk cevap: kimse beklememiş

Ham tarama şunu dedi: 500 paketin 481'i PHP 8.4'ü **daha çıkmadan önce** kabul
ediyordu. Kurulum payıyla %99,7. Gerçekten bekleyip sonradan kısıtını genişleten
paket sayısı sıfır.

Bu sonuç doğru ama işe yaramaz, çünkü "kabul ediyordu" cümlesinin altında şunlar
var:

| Paket | Kabul eden ilk sürüm | Tarih | Kısıt |
| --- | --- | --- | --- |
| symfony/console | 2.0.4 | 2011-09-26 | yok |
| psr/log | 1.0.0 | 2012-12-21 | yok |
| guzzlehttp/psr7 | 1.0.0 | 2015-05-19 | >=5.4.0 |
| psr/container | 1.0.0 | 2017-02-14 | >=5.3.0 |

2011'de yazılmış bir alt sınır, 2024'te çıkan bir sürüm hakkında hiçbir şey söylemez. Composer kurar; kodun çalışacağını kimse iddia etmiyor.

2015'te `>=5.4.0` yazan bir paket PHP 8.4'ü desteklediğini beyan etmiş olmuyor.
Sadece bir alt sınır koymuş oluyor. Composer bu ikisini ayırmaz — kurulumu
engellemeyen her şey "uyumlu" sayılır — ama okuyucu ayırmak zorunda.

## Kısıtların yarısı üst sınır yazmıyor

En çok kurulan 500 paketin 223'ü üst sınırı hiç kapatmıyor. Kurulum payıyla
**%56,4**. Bu kısıtlar bugün var olmayan PHP sürümlerini de kabul ediyor:

| Paket | Kurulum | Bugünkü kısıt | Ne demiş oluyor |
| --- | --- | --- | --- |
| symfony/console | 1,18 milyar | >=8.4.1 | PHP 12 dahil her şey |
| psr/log | 1,26 milyar | >=8.0.0 | PHP 12 dahil her şey |
| symfony/polyfill-mbstring | 1,26 milyar | >=7.2 | PHP 12 dahil her şey |
| psr/container | 1,10 milyar | >=7.4.0 | PHP 12 dahil her şey |

Symfony 8 PHP 8.4'ün altını kesiyor ama üstünü açık bırakıyor. Bu bir ihmal değil, bilinçli bir politika — ve beyanı geleceğe dönük olarak bilgisiz kılıyor.

Bu bir suçlama değil: üst sınır yazmak bakım maliyeti demektir, her yeni PHP
sürümünde bütün bağımlılık ağacını dolaşıp sürüm çıkarmak demektir. Açık uç, bu
maliyeti reddetmenin makul bir yolu. Ama sonucu şu: **ekosistemin yarısında
"destekliyor mu" sorusunun kısıtta bir cevabı yok.**

## Üst sınır yazanlarda tarih anlam kazanıyor

Geriye 280 paket kalıyor — kısıtı `^8.0` ya da `8.0 - 8.4` gibi üstten kapanan
paketler. Burada tarih bir şey söylüyor, çünkü `^8.0` yazmak bilerek verilmiş
ileriye dönük bir taahhüttür: "PHP 8'in tamamı."

| PHP | Üst sınır yazan | Önceden taahhüt | Sonradan genişleten | Hiç üst sınır yazmayan |
| --- | --- | --- | --- | --- |
| 8.2 | 265 | 201 | 64 | 194 |
| 8.3 | 274 | 223 | 51 | 199 |
| 8.4 | 280 | 247 | 33 | 202 |

Taahhüt edenlerin büyük çoğunluğu taahhüdünü sürüm doğmadan veriyor.

`guzzlehttp/guzzle` PHP 8.4'ü **Ekim 2020'de** kapsamış — sürümden dört yıl
önce, `^7.2.5 || ^8.0` yazarak. `phpunit/phpunit` Ağustos 2020'de, `doctrine/lexer`
Mayıs 2020'de. Caret işi yapıyor: bir kez "PHP 8'in tamamı" dediğinizde 8.1,
8.2, 8.3 ve 8.4 için bir daha dosyaya dokunmuyorsunuz.

> **Sonuç**
>
> Ekosistemin yeni bir PHP **minor** sürümünü hızlı benimsemesi bir çeviklik
> göstergesi değil, caret'in mekanik sonucu. Bu mekanizma PHP 9'da sıfırlanacak:
> `^8.0` yazan her paket 9.0'ı kabul etmeyecek ve aynı 280 paket aynı anda karar
> vermek zorunda kalacak. Bu kayıt, o gün tekrar koşulacak bir ölçüm bırakıyor.

## Bekleyenler ne kadar bekliyor

Gerçekten sonradan genişleten 33 paketin medyanı **325 gün**. Bir yıldan fazla.

| Paket | Kurulum | Gecikme | Genişlettiği kısıt |
| --- | --- | --- | --- |
| guzzlehttp/promises | 1,06 milyar | 546 gün | ^7.2.5 \|\| ^8.0 |
| theseer/tokenizer | 822 milyon | 362 gün | ^7.2 \|\| ^8.0 |
| myclabs/deep-copy | 923 milyon | 253 gün | ^7.1 \|\| ^8.0 |
| nette/utils | 454 milyon | 194 gün | 8.0 - 8.4 |

Bu paketlerin çoğu test ve altyapı katmanında duruyor: doğrudan yazdığınız kod değil, bağımlılığınızın bağımlılığı.

## Trend diye okunan şey sansür

Ham medyanlar sürümden sürüme düşüyor: 8.2 için 559 gün, 8.3 için 418, 8.4 için
325. "Ekosistem hızlanıyor" cümlesi buradan çıkar ve yanlıştır.

Sebep basit: 8.2'yi üç yıl yedi aydır izliyoruz, 8.4'ü bir yıl dokuz aydır. 8.4
için önümüzdeki bahar kısıtını genişletecek bir paket bugün görünmüyor, yani
8.4'ün medyanı dağılımın yalnız hızlı yarısından geliyor.

Üçünü de en kısa pencereye (639 gün) kırpınca:

| PHP | Ham medyan | İlk 639 günde genişleten | O pencerede medyan |
| --- | --- | --- | --- |
| 8.2 | 559 gün | 35 | 238 gün |
| 8.3 | 418 gün | 33 | 215 gün |
| 8.4 | 325 gün | 33 | 325 gün |

Trend kaybolmuyor, yön değiştiriyor: eşit sürede bakınca 8.4 öncekilerden daha yavaş benimsendi.

> **Sınır**
>
> Bu kaydın ölçtüğü şey **beyan edilen** destektir, sınanmış destek değil. `^8.0`
> kısıtı 8.4'ü kabul eder; paketin 8.4'te çalıştığını söylemez. Evren de "en çok
> kurulan" paketlerdir — geliştiricinin karşılaştığı ekosistemin makul bir
> örneği, Packagist'in tamamının değil. Uzun kuyruktaki bir paketin eski bir
> kısıtta oturma ihtimali çok daha yüksek, dolayısıyla buradaki sayılar
> ekosistemin **iyimser** ucudur. Son olarak `guzzlehttp/promises` gibi tek tek
> paketlerin gecikmeleri bakımcıya bir not değil: üst sınır yazmak gönüllü bir
> bakım yüküdür ve yazmayanların çoğu bunu bilerek yapıyor.

## Pratikte ne işe yarıyor

Bir yükseltmeyi planlarken `composer why-not php 8.4` çıktısına bakarsınız ve
orada duran paketlerin çoğu bu taramanın "üst sınır yazan" kohortundan gelir.
Diğer yarısı hiç görünmez — sizi engellemedikleri için değil, engelleyip
engellemeyeceklerini kimsenin bilmediği için. Beyan yokluğu bir yeşil ışık
değil, ölçülmemiş bir risk.

Ölçümün kendisi tekrar edilebilir: depoda `scan.mjs` ve 22 Ağustos 2026 koşusunun
ham JSON'u duruyor. PHP 9 çıktığında aynı komut, aynı 500 paket üzerinde çok
farklı bir tablo verecek — ve asıl sınav o olacak.