Gutenberg-Çekirdek Eşzamanlama Kuralları Yazıya Döküldü

Yayına aldığım her WordPress sürümünde aynı gizli bedel vardı. Gutenberg’de sorunsuzca biten bir editör çalışması, bir beta sonra WordPress çekirdeğinde biraz farklı bir derlemeyle, biraz farklı bağımlılıklarla ve kimsenin yerelinde tekrarlayamadığı sessiz bir hatayla karşımıza çıkıyordu. Yıllarca bunu “iki ayrı depo tutmanın bedeli” diye geçiştirdik. Bedavaya gelmiyor. Komiterlerin zamanını, beta test gönüllülerinin sabrını yiyor; geçen ay onayladığınız bir düzeltmenin WordPress trunk’ta neden başka davrandığını da çoğu zaman bu mesele açıklıyor.

Bu yüzden Make/Core’un, Gutenberg kodunun wordpress-develop içine nasıl akacağına dair yazılı, isim ve tarih taşıyan bir kurallar dizisini — sıklık, denetim listesi, commit mesaj şablonu ve hangi hash değerlerine izin verildiğinin açık listesiyle — yayımlaması önemli. Parlak bir konu olduğu için değil. WordPress’in sıkıcı kısmını öngörülebilir kıldığı için. Bir ajansın aslında müşteriye sattığı şey öngörülebilirliktir.

Bugün neyin değiştiğine, bu değişikliğin neden var olduğuna ve çekirdek commit’lerini bundan sonra nasıl okuyacağıma bakalım.

Asıl yeni olan ne

30 Haziran 2026’da Jonathan Desrosiers, Make/Core üzerinde Guidelines for Syncing Code From Gutenberg Into WordPress Develop başlıklı yazıyı yayımladı. Bu yazı, Gutenberg’in npm paketlerinin ve derlenmiş varlıklarının WordPress trunk’a nasıl indiğini anlatan ilk resmi, yazılı süreç. O güne kadar yanıt, bir avuç komiterin başında taşıdığı kurumsal bilgiydi — odadaysanız işe yarayan, dışarıdaysanız muğlak kalan bir bilgi.

Altta yatan mekanik değişiklik zaten devrede: Gutenberg deposundan wordpress-develop’a kod aktarımı, yayımlanmış npm paketlerinden çıkarak GitHub Container Registry üzerinden indirilen bir derleme arşivine geçti. Bu arşivi Gutenberg’deki build-plugin-zip.yml iş akışı üretiyor. Bu boru hattını tıkayan iki hata vardı; 62577–62578 ve 62580–62584 changeset’lerinde yapılan düzeltmelerden sonra WordPress trunk artık Gutenberg’in en güncel sürümü olan 23.4.0 ile aynı çizgide.

Manşet, eşzamanlama sıklığında. Alfa döneminde — bir nihai sürümle bir sonraki beta arasındaki uzun aralıkta — “eşzamanlama her Gutenberg genel sürümünden bir hafta sonra yapılacak.” Uzun vadeli hedef ise haftalık, hatta günlük eşzamanlama. Beta 1’den sonra trunk, Gutenberg’deki ilgili wp/X.Y dalına package.json içindeki gutenberg.sha değeriyle sabitleniyor; bu, istenmeyen özelliklerin WordPress’e sızmasını engellerken cherry-pick edilen düzeltmelerin girmesine izin veriyor. Her beta ve RC öncesinde eşzamanlama tekrarlanıyor. SVN dallanmasının ardından numaralı dal wp/X.Y‘ye sabitli kalıyor; trunk X.Y+1-alpha‘ya çıkıp en güncel Gutenberg sürümüne iki ayrı commit ile yeniden eşzamanlanıyor — biri sürüm yükseltmesi için, biri eşzamanlanan değişiklikleri belgelemek için.

Küçük sürümlerde ise alışıldık Trac dansı sürüyor — trunk’a commit, ticket’ı fixed-major ve commit dev-feedback ile işaretle, ikinci onaydan sonra commit dev-reviewed ile birleştir — bir yeni izinle birlikte: numaralı dallarda sabitlenmiş SHA değerlerini değiştiren commit’lere, çift onay süreci işletildiği sürece izin veriliyor. gutenberg.sha alanında yalnızca tam uzunlukta SHA değerleri kabul ediliyor; sürüm etiketleri, wp-X.Y etiketleri, PR etiketleri ve trunk, altyapı düzeyinde geçerli referans tipleri olsalar bile burada kullanılmıyor. Gerekçe idempotency: yalnızca değişmez referanslar, bugün ve altı ay sonraki bir checkout’un aynı kodu üretmesini garantiler.

Yazı ayrıca yeni bir bilet düzeni de oturtuyor. Derleme betiği dışındaki her değişiklik için yine ayrı Trac bileti açılıyor (eski uygulama). Her alfa-dönemi hash güncellemesi de artık kendi biletine sahip oluyor (yeni). Beta/RC hash güncellemeleri faz başına tek bir toparlayıcı biletle takip ediliyor — her commit’e ayrı bilet değil, “Gutenberg Syncs for Beta 2” gibi tek bir bilet (yeni). Commit mesajları; bileşen, hash aralığı, diff için GitHub bağlantısı, içerilen commit’lerin PR bağlantılı madde listesi, takip referansları, gözden geçirme kredisi, props ve bilet referansını içeren bir şablonu izliyor. Yazıda değişiklik listesini üretmek için tek satırlık bir git log komutu bile var.

Daha geniş bağlam için: bu süreç, 5 Haziran’daki WordCamp Europe 2026 Çekirdek Komiterleri toplantısının canlı bir sürtünme olarak işaretlediği konuyu — SVN ile Git çalışma ağaçları arasındaki Trac #64971‘in izlediği boşluğu — ve WordPress’in 2003’ten beri sürdürdüğü kararlı sürüm sözünü bozmadan nasıl daha hızlı hareket edileceği etrafındaki tartışmayı doğrudan ele alıyor.

WordPress ve WooCommerce tarafı için neden önemli

Site sahibiyseniz bu konu “iç işleyiş” gibi görünür. Değil. Eşzamanlama sıklığı, altı hafta önce X’te kutlanan bir Gutenberg düzeltmesinin müşterinizi yükselttiğiniz WordPress sürümüne gerçekten ulaşıp ulaşmadığını belirleyen şey. Geçen haftaya kadar “Bu Gutenberg PR’ı çekirdeğe ne zaman düşer?” sorusunun dürüst yanıtı “Bir komitere sorun” idi. Artık yanıt şu: “Bir sonraki Gutenberg nihai sürümünden bir hafta sonra; cycle Beta 1’i geçtiyse bir sonraki beta veya RC’den hemen önce.” Bu somut bir planlama aracı.

Ajanslar açısından kazanç, hata ayıklanabilirlik. Küçük bir sürümden sonra bir müşteri sitesinde regresyon yaşadığınızda, artık tek bir toparlayıcı bileti — örneğin “Gutenberg Syncs for 7.1 RC2” — gösterip tam hash aralığını ve içeriye giren tüm PR listesini görebilirsiniz. Önceden iki depo ve üç farklı dal adlandırması arasında changeset’leri tek tek kovalamak gerekiyordu. Çoğumuz kovalamadık. Birinin Trac biletini açmasını bekledik. Bu, sürdürülebilir bir katkıcı modeli değil.

Eklenti ve tema geliştiricileri için pratik sinyal şu: Beta ve RC kesim noktaları artık gerçek kesim noktaları. Beta 1’den sonra trunk wp/X.Y‘ye sabitleniyor ve içeriye yalnızca cherry-pick edilen düzeltmeler girebiliyor. Bir Gutenberg özelliğinin 19 Ağustos’taki WordPress 7.1 sürümüne yetişmesini istiyorsanız, onu Gutenberg’in wp/7.1 dalına indirme süresi zaten daralıyor. Bu pencereyi kaçıran her şey 7.2’ye kadar görünmüyor — ve “Bir sonraki eşzamanlamada yakalarım” artık geçerli bir savunma değil.

WooCommerce ağırlıklı işler için ikincil etki şu: WooCommerce 10.9 ve 11.0’in üzerine bahis oynadığı Gutenberg primitifleri — blok tabanlı Sepet ve Ödeme, Interactivity API store, Add to Cart with Options bloku — daha öngörülebilir bir alt davranış kazanıyor. Gutenberg-çekirdek eşzamanlamasının istikrarsız olması, son iki cycle’da blok tabanlı Woo’nun blok tabanlı içerikten daha pürüzlü olmasının sessiz nedenlerinden biriydi. Bu, pazarlama yazısında görünmeyen ama saat 02:00’deki Slack mesajlarının sayısında görünen türden bir boru hattı değişikliği.

Yerinde olsam ne yapardım, ne yapmazdım

Müşteri sitelerine yayın yapıyorsanız: bu hafta farklı bir şey yapmayın, ama önümüzdeki haftadan itibaren eşzamanlama biletlerini okumaya başlayın. Make/Core RSS’ine veya Slack kanalına abone olun, 15 Temmuz’da WordPress 7.1 Beta 1 indiğinde “Gutenberg Syncs for Beta 1” biletini takip edin ve PR listesini gözden geçirin. Bu beş dakikalık alışkanlık, iki beta arasında neyin geldiğini öğrenmenin artık en iyi yolu. Bunu yapmak için eskiden bir komiterin kafasına ihtiyacınız vardı. Artık yok.

Editör iç bileşenlerine bağlanan bir eklenti veya tema bakımı yapıyorsanız: Gutenberg trunk’a birleşmiş bir düzeltmenin WordPress trunk’a da ulaştığını varsaymayı bırakın. Test ettiğiniz WordPress dalındaki package.json‘da gutenberg.sha‘yı kontrol edin ve düzeltmenizin commit’inin bu aralıkta olup olmadığına bakın. Yazı, diff listesini üretmek için git log --reverse tek satırını da veriyor. Henüz eşzamanlanmamış bir şey için WordPress’e “regresyon” hatası açmadan önce bunu kullanın.

Commit erişimi olan veya bunu hedefleyen bir katkıcıysanız: yazıyı baştan sona, iki kez okuyun. Sonra bir eşzamanlama PR’ı açmadan önce üçüncü kez okuyun. Gözden geçirme listesi kısa — build:dev çalıştırıldıktan sonra yeni değişiklik olmaması, değişen dosyaların derleme betiğinin ürettikleriyle uyumlu olması, WordPress’in yerelde beklendiği gibi çalışması — ama bu üç madde, geçmişte trunk’ı saatlerce kıran arıza modlarını yakalayan maddeler.

Yapmayacağım şey: bunu bir kerelik bir iş gibi görmek. Yazı gelecekteki işleri açıkça listeliyor — eşzamanlama bileti oluşturmayı otomatikleştirmek, Core Handbook’taki commit mesaj kılavuzlarını güncellemek, Branching Before Release dokümantasyonunu yenilemek, büyük ve küçük sürüm denetim listelerini güncellemek. Bu bir süreç değişikliğinin sonu değil, başlangıcı. 7.1 cycle’ı boyunca rafine edilmesini bekleyin.

İlgi çekici altyapıyı mümkün kılan, sıkıcı altyapıdır. Knowledge içerik türü, AI Client, Notes özelliği, eş zamanlı düzenleme — hiçbiri öngörülebilir bir boru hattı olmadan güvenle inmez. WordPress nihayet o boru hattını bugün yazıya döktü.