Her sürüm döneminde müşterilerimden aynı soruyu duyuyorum: “Güncellemek güvenli mi artık?” Yirmi yıldır cevabım değişmedi. Güvenlik takvimdeki bir tarih değildir. Güvenlik, o tarihte tam olarak ne olduğunu, odada kimin bulunduğunu ve siteye gelmeden önce nelerin test edildiğini bilmektir.

Bu yüzden sürüm partisi takvimini yayımlandığı an okurum. Her yapının tam olarak ne zaman ineceğini, “commit” düğmesine kimin basacağını ve bir şey ters gittiğinde nerede olmam gerektiğini bana söylüyor. Bu bağlamı atlayınca her yükseltme tahmine dönüşüyor. Okuyunca WordPress 7.1’e planlı gireceksiniz.

7.1 takvimi artık resmileşti. Sektör yapay zekâ heyecanıyla nefes alıp verirken bir WordPress veya WooCommerce ajansının rahat uyumasını sağlayan türden sessiz, sıkıcı bir ayrıntı. Planın gerçekte ne söylediğini ve etrafında nasıl çalışacağımı aşağıda anlatıyorum.

Gerçekten yeni olan ne

3 Temmuz 2026’da Benjamin Zekavica, Make/Core üzerinde WordPress 7.1 Sürüm Partisi Takvimini yayımladı. Tüm 7.1 ekibinin hedeflediği son tarihi doğruluyor: 19 Ağustos 2026. O tarihe kadar altı kontrol noktası var; her biri Making WordPress Slack’teki #core kanalında ayrı bir partiyle geçecek.

  • Beta 1 — 15 Temmuz 2026, 15:00 UTC, @krupajnanda liderliğinde
  • Beta 2 — 22 Temmuz 2026, 15:00 UTC, @krupajnanda liderliğinde
  • Beta 3 — 29 Temmuz 2026, 15:00 UTC, @benjamin_zekavica liderliğinde
  • RC 1 — 5 Ağustos 2026, 15:00 UTC, @benjamin_zekavica liderliğinde
  • RC 2 — 12 Ağustos 2026, 15:00 UTC, @krupajnanda liderliğinde
  • Prova ve 24 saatlik dondurma — 18 Ağustos 2026, 15:00 UTC, iki lider birlikte
  • Genel Sürüm — 19 Ağustos 2026, iki lider birlikte

Bu partilerin arkasındaki değişmez rolleri de saymak gerek, çünkü sizin için takvimi asıl bu kişilerin ajandası tutar. Her aşamada işleyici (committer) @wildworks. Güvenlik koltuğunda @joedolson var. @sergeybiryukov ise Görev Kontrol’de oturup takvim ile Trac’i hizalıyor. Bu üçgen — işleyici, güvenlik, koordinasyon — canlı bir Slack partisini WordPress.org üzerinde gerçek, sürümlenmiş bir çıktı haline getiren şey.

Sürüm-liderliği koltuğunda Krupa Nanda ile Benjamin Zekavica dönüşümlü oturuyor; ikisi de Anne McCarthy’nin altında çalışıyor. McCarthy, 7.1 genel sürüm lideri. Bu yapı, Haziran ortasındaki 7.1 sürüm ekibi duyurusunda netleşmişti; 19 Haziran’da yayımlanan 7.1 yol haritası da aynı 19 Ağustos sonunu sabitliyor. Make/Core’u takip eden hiç kimseye takvimde sürpriz yok.

Bu duyuruda gerçekten işe yarayan şey, partilerin yapısı. Her şey tek bir Slack kanalında geçiyor. Fiziksel bir mekân yok. Zekavica açıkça yazıyor: “Genel Sürüm Partisi’ne katılmak için seyahat etmek ve etkinliğe fiziksel gelmek gerekmiyor.” #core‘a giriyorsunuz, test ediyorsunuz, sonucu bildiriyorsunuz. 6.8 döneminden kalan katkı rehberi adımları özetliyor: Slack’i kurun, kanala partiden yaklaşık on dakika önce girin, hedef yapıyı çalıştıran yerel bir WordPress test siteniz olsun, test listesini yürütün, sonucu basit bir geçti/kaldı işaretiyle raporlayın.

WordPress ve WooCommerce tarafında bunun önemi

7.1 yükü küçük değil. Yol haritası şunlara söz veriyor: editoryal kuralları kayda alan kalıcı bir Kılavuzlar (Guidelines) özelliği, öneri kipi ve emoji tepkileriyle güçlendirilen Notlar, akışlı üretim ve gömme (embedding) yeteneği kazanan yapay zekâ istemcisi (AI Client), üç yeni çekirdek blok (Playlist, Table of Contents, Tabs), Site Düzenleyici içinde CSS’e ihtiyaç duymadan çalışan duyarlı ve sözde-durum stil kontrolleri ve deney bayrağının arkasına dönen React 19 yükseltmesi. Bir mağaza ya da bir yayın sitesinin tek dönemde sindireceği epey yüzey.

Ekip takviminize özellikle iki tarihi işleyin. 15 Temmuz: Beta 1 iniyor ve trunk wp/7.1 dalına sabitleniyor — o günden sonra kırılma anlatan her geliştirici notu size hitap ediyor. 5 Ağustos: RC 1. Sorumlu eklenti ve tema geliştiricilerinin sürüm yapısına karşı tam bir tur atmış olması beklenen an. Özel eklentiniz veya WooCommerce entegrasyonunuz ancak 19 Ağustos’tan sonra test ediliyorsa, beta test eden sizsiniz; müşterinizin sitesi de aşama ortamıdır.

Parti yapısının bir başka pratik faydası: her şey herkese açık. RC 1 ile RC 2 arasında belirli bir yama ters teptiğinde aynı gün Slack üzerinden izini sürebilirsiniz. Sizi şaşırtan bir değişiklik yayına aktığında, tam olarak o partinin commit listesine bakarak hangi katkıcı ve hangi biletin işin içinde olduğunu görebilirsiniz. Müşterilere anlattığım olgunluk hikâyesi tam olarak bu — şeffaflık, iki ay sonra gelen bir sağlayıcı duyurusu değil, akışa gömülü bir özellik.

WooCommerce mağazaları için zamanlama daha da kritik. WooCommerce 11.0’ın çıkış tarihi 28 Temmuz 2026; yani WordPress 7.1’den üç hafta önce. Bu, 11.0’ın önce WordPress 7.0.x üzerine indiği, sonra 7.1’in React 19 deneyleri ve yeni düzenleyici blokları ile geldiği alışılmadık sıkı bir pencere yaratıyor. Ağustos sonunda ikisinde birden olmak istiyorsanız, testi son haftaya bırakamazsınız.

Yerinizde ne yapardım, ne yapmazdım

Kendi 7.1 hazırlığımı böyle yürütüyorum; sorumluluğumuzdaki her müşteri sitesine de aynısını tavsiye ediyorum.

  • 15 Temmuz ve 5 Ağustos’u ekip takvimine yerleştirin. Beta 1 ve RC 1, yetkin bir ajansın bakım ücretini hak ettiği iki penceredir. Diğerleri daha küçük ölçekli.
  • 14 Temmuz’a kadar bir 7.1 aşama sitesi kurun. Üretim kopyanız üzerinde WordPress Beta Tester eklentisini kullanın. Bleeding-edge ve nokta sürüm ayarına alın. Beta 1 indiğinde kendiliğinden çekecektir.
  • Her beta ve RC’de duman testinizi yürütün. Tam QA turu değil — o çok pahalı. Yalnızca para kazandıran on veya on beş akış: ödeme, iletişim formu, dayandığınız blok şablonları, başsız istemcilerin tükettiği özel REST uç noktaları.
  • Her geliştirici notunu okuyun. Field Guide, RC aşamasında derlenecek ama tekil notlar beta boyunca çıkıyor. Make/Core RSS akışına henüz abone değilseniz, olun.
  • Partiyi seyirci sporu gibi görmeyin. Beta 1 veya RC 1 günü 15:00 UTC’de #core‘da olun. Bir şeyi test edin. Sonucu bildirin. WordPress’in nasıl çıkış yaptığını, özet metinleri bir yıl okumaktan daha çok bir saatte öğrenirsiniz.

Yapmayacağım şey: 19 Ağustos’un kendisinde 7.1 yükseltmesini üretime itmek. 7.1.1’i beklemenin hiçbir sakıncası yok. Üç hafta önce 11.0’ı almış bir WooCommerce mağazasının üzerine, taze bir nokta-sıfır sürümü koymanın ise çok sakıncası var. Sürüm günü aşama ortamına, bir iki hafta sonra üretime — o ana kadar sahadan gelen ilk raporlar oturmuş, tozlar durulmuş olur.

Sürüm partileri kasıtlı olarak sıkıcıdır. Bu bir hata değil, bir özelliktir — parti ne kadar sıkıcıysa, sizin tarafınızdaki yükseltme o kadar pürüzsüz geçer.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Close Search Window