Ara sürümlere zaafım var. Manşet olmazlar, sosyalde gündeme düşmezler, ama bir projenin olgunluğu hakkında ana sürümden daha çok şey anlatırlar. Bir ekibin kullanıcısına ne kadar saygı duyduğunu, büyük lansmandan sonraki ilk düzeltme turunu ne kadar hızlı ve sessiz çıkardığına bakarak ölçebilirsin.
WordPress 7.0, 20 Mayıs 2026’da geniş bir yüzey alanıyla çıktı: AI Client, Connectors, Komut Paleti, iframe içine alınmış düzenleyici, görsel revizyonlar, yeni bloklar. Tek bir sürümde dört yüzden fazla Trac kaydı. Bir ay sahada kaldıktan sonra, küçük gerilemelerin ve pürüzlerin kaçınılmaz listesi sıraya girdi ve çekirdek ekibi takvimi duvara astı.
Bugün üzerinde duracağım şey o takvim, çünkü tarihler önümüzdeki üç hafta boyunca 7.0 üzerindeki her site planını doğrudan ilgilendiriyor.
Gerçekten yeni olan ne
18 Haziran 2026’da çekirdek ekibi 7.0.1 sürüm takvimini Make/Core üzerinde yayımladı. Sürümün dört eş lideri var: Carlos Bravo (@cbravobernal), Estela Rueda (@estelaris), Daniel Richards (@masteradhoc) ve Aaron Jorbin (@jorbin). Bir ara sürümde dört eş lider az şey değildir — bu, ekibin agresif şekilde ayıklama yapıp tarihi tutturmaya niyetli olduğunu gösterir.
Duyurudaki tarihler aynen şöyle:
- 18 Haziran 2026 — Hata ayıklama oturumu (geçti)
- 23 Haziran 2026 — Hata ayıklama oturumu
- 25 Haziran 2026 — Hata ayıklama oturumu ve 7.0.2 kilometre taşının açılışı (7.0.1’e yetişemeyen her şey buradan itibaren bir sonraki ara sürüme kuyrukta bekler)
- 30 Haziran 2026 — Hata ayıklama oturumu
- 1 Temmuz 2026 — Aday Sürüm 1 (RC1)
- 7 Temmuz 2026 — Hata ayıklama oturumu
- 9 Temmuz 2026 — Genel sürüm
Kapsam bilinçli olarak dar: “WordPress 7.0.1, yalnızca hata düzeltmeye yönelik bir bakım sürümü olarak planlanmıştır. Yalnızca 7.0 döngüsünde ortaya çıkan ya da döngünün sonunda bilinçli olarak ertelenen kayıtlar dahil edilecektir.” Çeviri: yeni özellik yok, geliştirme yok, performans yenilenmesi yok. Sevdiğin eski bir pürüz 7.0 ile gelmiş bir gerileme değilse bu trene binmez.
7.0’ın gerçekte neyi değiştirdiğini ve bu nedenle hangi tür hataların yüzeye çıkma olasılığının yüksek olduğunu bilmek için önemli bir bağlam: resmi WordPress 7.0 Saha Kılavuzu‘na göre sürümde yeni AI Client ve Connectors ekranı, Modern renk şeması, Komut Paleti, iframe içine alınmış yazı düzenleyici, görsel revizyonlar, duyarlı blok görünürlüğü, yalnızca PHP ile blok kaydı, Block Bindings desen geçersiz kılmaları ve genişletilmiş Interactivity API yer aldı — üstüne çekirdeğin 419’u aşan kaydı ve düzenleyici ile panoda çok daha büyük bir yığın. Şu anda taranan yüzey bu.
Takvim 25 Haziran’da 7.0.2 kilometre taşını da açıyor. Bu, ekibin ikinci bir ara sürüm beklediğini söylemenin nazik yolu. 7.0 dönemine ait bir hata bildirdiysen ve 9 Temmuz kesimine yetişmezse oraya düşer. Düzeltmelerin güncel listesini duyuruda bağlantısı verilen Trac raporu 4 ve 7.0.x GitHub proje panosu üzerinden takip edebilirsin.
Kimsenin konuşmadığı ama konuşması gereken bir zamanlama daha var: 7.1 beta 1, 7.1 yol haritası ve 7.1 sürüm ekibi duyurusu uyarınca 15 Temmuz’da çıkıyor. Bu, projeye 7.0.1’i çıkarmak ile 7.1 betasına girmek arasında altı günlük bir boşluk veriyor. Ekipler bilinçli olarak ayrı tutuldu ama test eden topluluk aynı insanlar ve yoğun olacaklar.
Bir zamanlar “yama” diye bir şey yoktu
Şu “9 Temmuz’da düzeltme geliyor, on gün sonra 7.0.2 kuyruğu açık” rahatlığına bakınca, bunun ne kadar yeni bir lüks olduğunu genç kuşağın çoğu bilmiyor. Ben CD-ROM projeleri ürettiğim yıllardan geliyorum. O dünyada bir yazılımı bitirdiğinde “altın master” denen tek bir diski basar, çoğaltma tesisine yollardın. O disk fabrikadan on binlerce kopya halinde çıktığı an, içindeki her hata sonsuza kadar orada kalırdı. Yama yok, güncelleme sunucusu yok, “0.1 sürümünde düzeltiriz” yok. Bir virgül hatası, kutulanmış on bin diskin üstünde yaşardı.
O disiplin bir korku kültürü yaratırdı — çünkü yaratmak zorundaydı. Master’ı yollamadan önce haftalarca, listelerle, ekranı ekrana test ederdik; çünkü “sonra düzeltiriz” diye bir sonra yoktu. Bugün WordPress’in bir ara sürüm takvimini duvara asabilmesi, RC çıkarıp genel sürümden önce bir hafta bekleyebilmesi, o eski korkunun yerine koyduğumuz en büyük konfor. Ama açık konuşayım: yama yapılabilir olması, dikkatsiz olmak için bir bahane değil. 7.0.1’in dar kapsamı — sadece gerilemeler, yeni özellik yok — tam olarak o eski disiplinin modern, medeni hali. Yamanın varlığı testi ucuzlaştırmaz; sadece bir hatanın maliyetini “on bin disk” olmaktan çıkarıp “bir sonraki salı” yapar.
WordPress / WooCommerce dünyasındakiler için neden önemli
Müşteri sitelerini 7.0’a güncellediysen, 9 Temmuz “ha, bu artık düzelmiş” diyen ilk e-posta dalgasının geleceği gün olacak. Komut Paleti, iframe içindeki düzenleyici, yeni görsel revizyonlar arayüzü ve AI Connectors — gerilemelerin uç durumlarda saklandığı türden yüzey alanları. Sağdan sola yönetim arayüzü, 6.9’da sorunsuz çalışan özel bloklar, yeni alanları beklemeyen REST tüketicileri. Hata düzeltme ara sürümleri bu tarz şeylerin indiği yerdir.
Henüz 7.0’a geçmediysen — hâlâ 6.9.x üzerinde bekleyen bir sürü ajans müşterisi var — filoda standartlaştırılacak sürüm 7.0 değil, 7.0.1 olmalı. Bir ana sürümü tüm müşterilere yaymadan önce ilk ara sürümü beklemeyi alışkanlık haline getirdik. Bu örüntü yıllardır tutuyor, 7.0’ın onu bozmasının bir nedeni yok.
WooCommerce kurulumları için takvim daha da sıkışıyor. WooCommerce 10.9 beta aşamasında: 10.9 beta yazısı‘na göre çekirdekteki varyasyon galerileri, renk seçicileri, ikili API ve e-posta şablonu güncellemeleri geliyor. 10.9 sürümü, WordPress 7.0.1 ile aynı pencereye düşüyor. Her ikisini birden çalıştırdığın bir yığın varsa kombinasyonu çıkıştan önce test etmek istersin, sonra değil.
Sunucu sağlayıcıları için: ara sürümler otomatik güncelleme verilerinin gerçekten bir şey ifade etmeye başladığı andır. Bir ana sürümde “sitelerin %X’i 24 saat içinde güncellendi” demek yarı anlamsızdır, çünkü içinde temkinli yöneticileri de barındırır. 7.0.1 gibi bir sürümde aynı oran, güncelleme altyapın hakkında gerçek bir şey söyler.
Ben ne yapardım (ya da yapmazdım)
Önümüzdeki üç hafta için üç somut hamle.
Birincisi: bu hafta 7.0 üzerindeki müşteri listeni tara ve her siteyi bir hazırlık durumu ile etiketle. “Otomatik güncelleme açık, 7.0.1’e binecek”, “manuel güncelleme penceresi planlandı”, “X eklentisi engelliyor, önce satıcı yamasını bekliyor”. Bu listeyi 9 Temmuz’da değil, 9 Temmuz’dan önce hazır istersin. Bir satıcı eklentisi hâlâ 7.0 uyumsuzluğu işaretliyorsa hatayı şimdi aç ve 7.0.1 kilometre taşında olup olmadığını Trac raporu 4 üzerinden takip et.
İkincisi: 7.0 dönemine ait raporladığın ama henüz ayıklanmamış bir kayıt varsa şimdi öne çıkar. Hata ayıklama oturumları 23, 25 ve 30 Haziran’da. Triyajcıların yeni yorumları aktif okudukları zaman o zaman. Bir PR’ın içine konmuş yeniden üretilebilir test senaryosu ya da bir Playground blueprint’i, bir paragraf düz yazıdan çok daha hızlı dönüştürür. Oturum takvimi duyuruda; iş Slack’te #core üzerinde dönüyor.
Üçüncüsü: 9 ya da 10 Temmuz’a kendi yayınlarını yığma. Her WordPress ara sürümünden sonra iki iş günü boyunca müşteri yayın pencerelerimizi kapatıyoruz. Ara sürümler tehlikeli olduğu için değil — döngünün genelde en güvenli sürümleridir — bir şey araştırılması gerekirse temiz bir suçlama dağılımı isteriz. Çekirdek güncellemesiyle aynı gün çıkan bir değişiklik, ters giden her şeyin suçunu —haklı ya da haksız— yüklenir.
Yapmayacağım bir şey: 7.0.1’i atlayıp Ağustostaki 7.1’i beklemek. 7.1’in yüzey alanı çok daha geniş (bir bayrak arkasında geri dönen React 19, AI Client akış desteği, Connectors kimlik doğrulama genişlemesi, Notes ve 7.1 yol haritası‘ndaki üç yeni blok). 7.0’dan 7.0.1’i atlayarak 7.1’e geçmek, birinin gerilemelerini taşımak ve diğerinin yüzey alanını aynı güncellemede üstlenmek anlamına gelir. Bu daha iyi değil, daha kötü bir risk profilidir.
Ara sürümler gösterişli değildir. Çoğu içerik yönetim sistemi taklitçisinin ulaşamadığı olgunluk eğrisinin parçasıdır. 9 Temmuz’u takvime işaretle ve sıkıcı oyunu oyna.
Last modified: Ağustos 2, 2026
United States / English 
Slovensko / Slovenčina 
Canada / Français 
Türkiye / Türkçe