GitHub API 2026-03-10 sürümü PR yanıtlarından merge_commit_sha alanını kaldırıyor

Ne değişti

GitHub'ın 2026-03-10 sürümü REST API'si, pull request payload'larında artık merge_commit_sha alanını içermiyor. dev.to'da yayımlanan ve aslında DriftSignal blogunda ortaya çıkan bir yazıya göre bu alan, pull request döndüren her endpoint'ten gitti; tek PR okumaları, PR listeleri ve event'ler dahil.

Kaldırılmayı çalışma zamanında haber veren hiçbir şey yok. Endpoint'ler HTTP 200 ve düzgün biçimlendirilmiş JSON döndürmeye devam ediyor; dolayısıyla birleştirilmiş bir PR'ın hangi commit olarak yerleştiğini öğrenmek için bu alanı okuyan kod, exception yerine null veya undefined alıyor ve otomasyon veri hâlâ oradaymış gibi çalışmaya devam ediyor.

Hata nerede ortaya çıkıyor

Hiçbir şey fırlatmadığı için hasar aşağı doğru yüzeye çıkıyor. Yazının örnekleri: yanlış commit'i dağıtan bir deployment, çöp üreten bir changelog üreteci ya da artık var olmayan bir SHA ile yorum yapan bir bot. Sürüm yükseltmesi ile görünür belirti arasındaki boşluk günlerce ya da haftalarca sürebilir; genellikle ikisini birbirine bağlayan kimsenin olmayacağı kadar uzun bir süre.

Aynı sürümdeki diğer sessiz kaldırmalar

Yazı, 2026-03-10'daki breaking change'leri incelediğinde bunların çoğunun çalışma zamanında görünmez kaldığını tespit ediyor:

• Tekil assignee alanı Issues ve Pull Requests'ten kaldırıldı. Bu alan assignees dizisini tekrarlıyordu ve yıllardır yolun sonundaydı; ancak hâlâ issue.assignee okuyan eski entegrasyonlar artık hiçbir şey almıyor — tekil alanı kontrol eden bir triage botu her issue'nün atanmamış olduğuna karar verirdi.
• has_downloads, on yılı aşkın bir deprecation süresinin ardından Repository yanıtlarından kayboldu. Buna göre dallanan kod, şikayet etmeden yanlış dala giriyor.
• Code scanning setup yanıtlarında javascript ve typescript dil değerleri tek bir javascript-typescript değeriyle değiştirildi. Eski enum'a göre yazılmış eşitlik kontrolleri ve switch ifadeleri basitçe eşleşmemeye başlıyor.
• cvss, advisory ve Dependabot alert API'lerinde cvss_severities lehine deprecate edildi; şiddet verileri yeni bir iç içe yapıya taşındı. Yazı bunun özellikle riskli olduğunu söylüyor, çünkü eski yolu okuyan güvenlik workflow'ları artık null şiddet değerleri görüyor.
• Bir beta media type yeniden adlandırmasından kalıntılar anahtarları değiştiriyor — user, owner oluyor; master_branch, default_branch oluyor. Parser'lar hata fırlatmıyor; sadece üzerine inşa edildikleri isimlerin altında değer bulmayı bırakıyorlar.

Yazı ayrıca bazı status code değişikliklerinden ve artık işi arka planda işleme devreden birkaç endpoint'ten bahsediyor.

Sürümü sabitlemek sorunu sadece erteliyor

GitHub API sürümlerini tarihliyor ve istemcilerin X-GitHub-Api-Version header'ı üzerinden seçim yapmasına izin veriyor; yazı da bu header'ın serbest bırakılmak yerine sabitleştirilmesini öneriyor. Ancak sabitlemenin bir çözüm değil, erteleme taktiği olduğunu üç gerekçeyle savunuyor.

Birincisi, GitHub yeni bir sürüm çıktıktan sonra önceki sürümü en az 24 ay boyunca destekliyor; yani her sabitleme kalıcı bir cevap değil, bir geri sayım taşıyor.

İkincisi, sabitleme yalnızca sürümlendirilmiş breaking change'lere karşı korur. Davranış sürümler arasında kayabilir — default'lar değişir, her zaman dolu gelen alanlar uç durumlarda boş dönmeye başlar — ve bunların hiçbiri tarihli bir sürümü beklemez.

Üçüncüsü, sabitlemeyi yükselttiğiniz gün hiçbir şey gürültülü şekilde başarısız olmaz. Kod derlenir, testler geçer, API başarı döner; ve almayı bıraktığınız alanlar, tam olarak testlerinizin hiç assert etmediği alanlardır, çünkü testler yeni sürümün sahip olduğunu varsaydığınız sözleşmeyi test eder.

Önerilen kontroller

Bir ekip 2026-03-10'a geçmiş olsun ya da olmasın, yazı aynı savunmaları öneriyor: sistem sınırında yanıtları bir şemaya karşı doğrulayın ki eksik bir alan null olarak akıp gitmek yerine hata verebilsin; yalnızca status code'lara değil, bağımlı olduğunuz payload değerlerine assert edin; geçmeden önce eski sürümün gerçek bir yanıtını aynı isteğin yeni sürümdeki yanıtıyla karşılaştırın; ve bu kontrolü düzenli bir takvimde tekrarlayın, çünkü bir sonraki sürüm çoktan hazırlanıyor.

Belirtilmeye değer bir uyarı: DriftSignal, canlı API'leri OpenAPI spec'lerine karşı izleyen araçlar satıyor; dolayısıyla yazının bu çerçevede ticari bir çıkarı var. Anlattığı alan kaldırmaları, yine de GitHub'ın kendi changelog'una karşı doğrulanmaya değer değişiklikler türünden.

Neden önemli

Yazının kendi ifadesiyle GitHub burada özenli örnek — tarihli sürümler, yayımlanmış bir changelog, uzun bir destek penceresi. Yine de breaking change, başarılı bir yanıttan bir alanın kaybolması olarak geliyor ve hata daha sonra başkasının pipeline'ının içinde yüzeye çıkıyor. GitHub PR verisi tüketen her deployment script'i, release aracı ya da bot, kaldırılan alanları — merge_commit_sha ile başlayarak — hemen şimdi aramalı, çünkü çalışma zamanında bu kırılmayı duyuracak hiçbir şey olmayacak. Ve dikkatle sürümlendirilmiş bir API bile bu kadar sessiz başarısız olabiliyorsa, çoğu sistemin bağımlı olduğu sürümlendirilmemiş üçüncü taraf API'leri aynı şeyi çok daha az uyarıyla yapabilir.