Godot Sürümleri Güvenle Nasıl Yükseltilir

Giriş

Proje devam ederken oyun motorunun sürümünü yükseltmek, oyun geliştirmedeki rutin kararların en korkutucularından biridir. Yeni bir Godot sürümü, sizi engelleyen hatayı düzeltmiş olabilir — ya da altı aylık emeğinizi taşıyan bir sahneyi sessizce bozabilir. Bu yüzden Godot topluluğundaki deneyimli geliştiriciler, sürüm yükseltmeyi sıradan bir iş olarak değil, bir risk kararı olarak ele alır.

Bu rehber "her zaman yükseltin" savunuculuğu değildir. Godot 4.x'ten 4.x'e geçiş için bir risk yönetimi kontrol listesidir: yükseltip yükseltmemeye nasıl karar verilir, güvenle geri dönebilmek için nasıl hazırlanılır, sürümler arasında nelerin bozulduğu bilinir ve — en önemlisi — hiçbir şeyin bozulmadığı gerçekten nasıl doğrulanır.

Gerçekten Yükseltmeli misiniz?

Herhangi bir şeye dokunmadan önce bu soruya dürüstçe cevap verin. Yükseltmenin gerçek bir maliyeti vardır (geçiş çalışması + yeniden test), dolayısıyla faydanın da aynı ölçüde gerçek olması gerekir.

Şu durumlarda yükseltin…

• Motor tarafında düzeltilmiş bir hata sizi engelliyorsa. Sorununuz daha yeni bir sürümde zaten düzeltilmişse, yükseltmek genellikle sonsuza dek geçici çözümlerle uğraşmaktan daha ucuzdur.
• Yeni bir özellik oyununuza somut fayda sağlıyorsa. "Kulağa hoş geliyor" düzeyinde değil — size gerçek geliştirme süresi kazandıran ya da ihtiyaç duyduğunuz bir tasarımı mümkün kılan bir özellik olmalı.
• Geliştirme süreniz uzunsa. Projeniz yıllar sürecekse, küçük ve sık sıçramalar (her seferinde bir minör sürüm) sondaki tek bir dev sıçramadan çok daha güvenlidir. Aradaki fark yalnızca büyür.

Şu durumlarda yükseltmeyin…

• Yayına yakınsanız. Çıkıştan önceki haftalar, motor düzeyinde değişiklik yapmak için olabilecek en kötü zamandır. Önce yayınlayın, sonra yükseltin.
• C# + Web dışa aktarımına ihtiyacınız varsa. C# projeleri için Web dışa aktarımı Godot 4.x'te hâlâ mevcut değil (godot#70796'da takip ediliyor). 3.x'te buna güveniyorsanız, 4.x'e geçmek bunu ortadan kaldırır.
• Eski donanımı hedefliyorsanız. Godot 3.x, OpenGL 2 sınıfı GPU'larda çalışır; Godot 4'ün Compatibility işleyicisi OpenGL 3.3 / WebGL 2 gerektirir. Kitleniz eski makineler kullanıyorsa, 3.x gerçekten doğru motor olabilir.
• Kritik eklentiler henüz güncellenmediyse. Projenizin bağımlı olduğu bir eklenti yeni sürümü desteklemiyorsa, kendi geçiş sorununuzun üzerine onunkini de devralırsınız.

Yükseltmeden Önce — Hazırlık Kontrol Listesi

Buradaki her adım tek bir amaç için var: yükseltme ters giderse kaybettiğiniz şeyin bir proje değil, bir öğleden sonra olması.

1. Her şeyi commit'leyin ve bir yükseltme dalı oluşturun. Projenizin tek kopyasını asla doğrudan yükseltmeyin. Ayrı bir dal (git kullanmıyorsanız klasörün tam bir kopyası), geri dönmenin bir kurtarma operasyonu değil, tek bir komut olması demektir.
2. Mevcut sürümünüzü tam olarak kaydedin (örn. hangi 4.x.y derlemesi, standart mı .NET mi). Geri dönmeniz ya da hata bildirmeniz gerekirse buna ihtiyacınız olacak.
3. Eski editör dosyasını saklayın. Godot sürümleri yan yana kurulabilir — editör tek bir çalıştırılabilir dosyadır, dolayısıyla ikisini birden tutmanın maliyeti sıfırdır ve eski dalı istediğiniz an eski editörle açabilirsiniz.
4. Eklentilerinizi listeleyin ve her birinin desteklediği sürümleri kontrol edin. addons/ klasörünü gözden geçirin, her birinin nereden geldiğini not edin ve deposunda ya da Asset Library sayfasında hedef sürümü desteklediğini doğrulayın.
5. Atlayacağınız her sürümün resmi yükseltme notlarını okuyun. Resmi geçiş rehberleri sürüm başına yazılır — 4.2'den 4.4'e geçiyorsanız hem 4.3 hem de 4.4 notlarını okuyun.
6. "Bilinen iyi durum" kanıtı toplayın. Önemli sahnelerinizin ekran görüntülerini alın, kısa bir oynanış videosu kaydedin ya da — en iyisi — otomatik test senaryoları yazın (aşağıdaki test bölümünde ayrıntılı olarak ele alınıyor). Yükseltmeden sonra "görünüm ve davranış aynı mı?" sorusuna ancak "aynı"nın ne anlama geldiğini önceden kaydettiyseniz cevap verebilirsiniz.

Yükseltme Prosedürü

1. Dal kopyasını yeni editörle açın. Ana dalı değil, yükseltme dalını. Yeni editör dönüştürme/yeniden içe aktarma önerecektir — kabul edin.
2. Yeniden içe aktarmasına izin verin. .godot klasörü sıfırdan yeniden oluşturulur. Büyük projelerde ilk içe aktarma biraz zaman alabilir ve bu ilk geçiş sırasında yazdırılan uyarılar genellikle zararsızdır.
3. Output ve Debugger panellerinde yeni hataları kontrol edin. Yükseltmeden önce zaten var olan hatalarla karşılaştırın (onları not etmiştiniz, değil mi?). Yeni hatalar, geçişin yapılacaklar listesidir.
4. Kritik yolları baştan sona oynayın. Yeni bir oyun başlatın, bir kayıt yükleyin, temel oynanış döngüsünü çalıştırın, ana menüleri açın. Editör zamanı hataları işin kolay kısmıdır — regresyonlar çalışma zamanı davranışında saklanır.
5. Test senaryolarınızı çalıştırın (yükseltmeden önce hazırladıklarınızı) ve temel çizgiyle karşılaştırın.
6. Commit'lemeden önce git'te çalışma ağacının farkını inceleyin. Editör geçiş sırasında dosyaları yeniden yazar: project.godot yeni yapılandırma değerleri alır, .tscn dosyaları yeniden kaydedilir ve yeni .uid dosyaları ortaya çıkabilir. Neyin değiştiğini tam olarak bilmek için farkı gözden geçirin — ardından bunu tek, net etiketlenmiş bir geçiş commit'i olarak kaydedin.

4.x Sürümleri Arasındaki Bilinen Kırılma Noktaları

Godot 4'ün minör sürümleri büyük ölçüde uyumludur, ama bu cümledeki "büyük ölçüde" ifadesi epey iş görüyor. Resmi notlara ve topluluk raporlarına göre en çok sorun çıkarma olasılığı olan değişiklikler şunlar.

4.2 → 4.3: TileMap kullanımdan kaldırıldı, yerine TileMapLayer geldi

Godot 4.3, TileMap düğümünü kullanımdan kaldırıp yerine TileMapLayer'ı getirdi — tek düğüm içindeki katmanlar yerine katman başına bir düğüm. Mevcut TileMap'ler çalışmaya devam eder, ancak yeni kod ve yeni projeler TileMapLayer kullanmalı. Editörde bir çıkarma aracı var: TileMap'inizi seçin, alttaki TileMap panelini açın, sağ üst köşedeki araç kutusu simgesine tıklayın ve "Extract TileMap layers as individual TileMapLayer nodes" seçeneğini seçin.

4.3 → 4.4: .uid dosyaları ve GDScript eklemeleri

• Godot 4.4, betiklerin ve gölgelendiricilerin yanına .uid eşlik dosyaları ekledi. Bunları sürüm kontrolüne commit'leyin — silinmeleri, kullanıldıkları her yerde uid:// referanslarını bozabilir (resmi 4.4 yükseltme notları, @export_file yollarının uid:// olması gibi ilgili değişiklikleri kapsıyor). Çöp gibi görünürler; çöp değiller.
• Tipli Dictionary'ler ve diğer GDScript eklemeleri geriye dönük uyumludur — eski kodunuz çalışmaya devam eder. Ancak yeni özellikleri benimseyen eklentiler eski sürümlerde çalışmaz hale gelir, bu yüzden sıçrama sonrası eklenti davranışı farklılaşabilir.

Genel: her minör sürüm arasındaki ince değişiklikler

Minör sürümler arasındaki işleme (rendering) ayarlamaları, oyununuzun görünümünü fark edilmesi güç biçimde değiştirebilir — aydınlatma, kenar yumuşatma, 2D hizalama. Topluluk tartışmalarında, temiz projelerde yeniden üretilemeyen sahneye özgü regresyonlar da yer alıyor: bir sahne yükseltmeden sonra hatalı davranıyor, ama aynı sahne temiz bir projede yeniden kurulduğunda sorunsuz çalışıyor. Bir şey açıklanamaz biçimde bozulursa şu yalıtma sırasını deneyin: editörü kapatın, .godot klasörünü silin, yeniden açıp her şeyin yeniden içe aktarılmasına izin verin; sorun devam ederse, suçlunun projenizde birikmiş durum mu yoksa gerçek bir motor değişikliği mi olduğunu belirlemek için sahneyi temiz bir projede yeniden üretin.

3.x → 4.x bambaşka bir hikâye

Yukarıdakilerin tamamı 4.x'ten 4.x'e sıçramalarla ilgili. Godot 3'ten Godot 4'e geçiş tamamen farklı bir kategoridir: GDScript sözdizimi değişti, birçok düğüm yeniden adlandırıldı; TileMap, fizik ve işleme sistemleri temelden yeniden yapıldı — ve çoğu eklenti özel 4.x sürümlerine ihtiyaç duyar. Büyük 3.x projelerinde geçiş maliyeti, yeniden inşa maliyetine yaklaşabilir ve buna değip değmeyeceği gerçekten projeden projeye değişen bir karardır. Bu geçiş kendi dokümantasyonunu hak ediyor (ve zaten var); bu makale onu kapsıyormuş gibi yapmayacak.

Yükseltme Sonrası Test — Asıl Darboğaz

İşin dürüst kısmı şu: geliştiricilerin yükseltmekten kaçınmasının bir numaralı nedeni geçişin kendisi değil — "hiçbir şey bozulmadı"yı elle doğrulamanın pahalı olması. Orta ölçekli bir oyunda eksiksiz bir manuel regresyon turu koca bir hafta sonunu yutabilir. Ve yayından sonra oyuncularınızın bulduğu bir çalışma zamanı hatası, herhangi bir editör hatasından çok daha kötüdür; çünkü artık bir yapılacaklar maddesi değil, bir itibar sorunudur.

Asgari manuel duman testi

• Başlık ekranından yeni bir oyun başlatın
• Mevcut bir kayıt dosyasını yükleyin
• Temel oynanış döngüsünü birkaç dakika oynayın
• Desteklediğiniz her çözünürlük ve pencere modunda arayüzü kontrol edin

Öncesi/sonrası karşılaştırmasını otomatikleştirin

Manuel tur ölçeklenmez ve bir sprite'ın iki piksel kaydığını size söyleyemez. Godot QA tam olarak bunun için yapıldı — Godot için ücretsiz, MIT lisanslı, açık kaynaklı bir test çalıştırıcısı. İş akışı, sürüm yükseltmelerine kusursuz oturuyor:

1. Yükseltmeden önce, kritik yollarınızı kapsayan senaryo JSON dosyalarını yazın (ya da kaydedin) ve eski sürümde temel ekran görüntülerini alın.
2. Yükseltmeden sonra, yeni sürümde tamamen aynı senaryoları çalıştırın ve temel görüntülere karşı piksel farkı alın.
3. Başarısız adımlar regresyonların yerini gösterir — bir hafta sonu süren manuel tekrar yerine dakikalar içinde.

Bir senaryo, adımlardan oluşan basit bir JSON listesidir — girdiler, beklemeler, doğrulamalar, ekran görüntüleri:

{
  "name": "core_loop_smoke",
  "steps": [
    {"type": "wait", "seconds": 1.0},
    {"type": "input", "action": "ui_accept", "pressed": true},
    {"type": "wait", "seconds": 0.5},
    {"type": "assert", "node_path": "/root/Main/Player",
     "property": "health", "expected": 100, "operator": "eq"},
    {"type": "input", "action": "move_right", "pressed": true},
    {"type": "wait", "seconds": 2.0},
    {"type": "input", "action": "move_right", "pressed": false},
    {"type": "assert", "node_path": "/root/Main/Player",
     "property": "position:x", "expected": 100.0, "operator": "gt"},
    {"type": "screenshot", "name": "after_move"}
  ]
}

Aynı senaryo formatı, Godot MCP Pro'nun run_test_scenario aracının kullandığı formattır; yani editörünüze bağlı bir yapay zekâ asistanı bu senaryoları sizin için yazabilir.

Bir Şey Bozulursa

1. Sürüme göre ikili arama yapın. Birden fazla minör sürümü tek seferde atladıysanız, tam olarak nerede bozulduğunu bulmak için yükseltmeyi bir seferde bir minör sürüm ilerleyerek yeniden deneyin. Bu, arama alanını "her şey"den tek bir değişiklik günlüğüne indirger.
2. .godot klasörünü temizleyin ve projenin yeniden içe aktarılmasına izin verin. Yükseltme sonrası tuhaflıkların şaşırtıcı bir kısmının nedeni bayat içe aktarma önbellekleridir.
3. Motorun GitHub issue'larında tam hata mesajınızı arayın. Gerçek bir regresyonsa, çoğu zaman biri onu zaten bildirmiştir — bazen bir geçici çözümle birlikte.
4. Suçlunun bir eklenti olup olmadığını kontrol edin. Proje Ayarları'ndan eklentilerinizi devre dışı bırakıp yeniden test edin. Sorun kaybolursa suçlu eklentidir — motoru suçlamadan önce güncellenmiş bir sürüm olup olmadığına bakın.
5. Eski sürümde kalmanın geçerli bir sonuç olduğunu kabul edin. Düzeltme maliyeti yükseltmenin faydasını aşıyorsa, dalı geri alın, olduğunuz yerde kalın ve bir sonraki sürüm çıktığında yeniden denemek için bir hatırlatıcı kurun. Bu başarısızlık değildir — risk yönetiminin işe yaramasıdır.

Yerinizde Kalmanın Doğru Karar Olduğu Durumlar

Bazı projeler kesinlikle yükseltilmemeli ve bunu açıkça söylemek gerekiyor: yayınlanmış ya da yayına çok yakın oyunlar, web dışa aktarımına ihtiyaç duyan C# projeleri, eski donanımı hedefleyen oyunlar ve ağır şekilde değiştirilmiş özel motor derlemeleri üzerindeki projeler. Bütün bu durumlarda, kullandığınız sürüm işini yapıyor demektir. Yükseltme bir araçtır, erdem değil — hedef bitmiş bir oyundur, yepyeni bir motor değil.

SSS

Yükselttikten sonra sürüm düşürebilir miyim?

Hayır, güvenilir biçimde yapılamaz. Yeni editör sahnelerinizi ve kaynaklarınızı yeniden kaydettiği anda, bunlar eski editörlerle geriye dönük uyumlu olmaktan çıkar. Geriye dönmenin tek güvenli yolu sürüm kontrolünden geri yüklemektir — yükseltme dalının var olma nedeni tam olarak budur.

Birden fazla sürümü tek seferde atlamalı mıyım?

Küçük sıçramalar daha güvenlidir. Resmi yükseltme notları sürüm başına yazılır, dolayısıyla her sıçramanın bilinen bir kontrol listesi vardır — çok sürümlü bir atlama hepsini aynı anda üst üste yığar ve hangi değişikliğin neyi bozduğunu ayırt etmeyi zorlaştırır.

Minör sürümler gerçekten bir şeyler bozar mı?

Nadiren, ama evet. Çoğu proje minör sürümleri sorunsuz atlar, ancak topluluk tarafından bildirilen uç durumlar mevcut — sıfırlanan çarpışma bitleri, sahneye özgü işleme regresyonları. Yükseltmeden önceki temel testlerin önemli olmasının nedeni tam da bu: "Bir şey bozuldu mu?" sorusunu bir histen bir ölçüme dönüştürürler.

Bu kontrol listesi 3.x → 4.x için de geçerli mi?

Kontrol listesinin kendisi evet — dal oluşturun, eski ikili dosyayı saklayın, temel görüntüleri alın, sonrasında test edin. Kırılma noktaları listesi ise hayır: 3'ten 4'e geçiş çok daha büyüktür (GDScript sözdizimi, yeniden adlandırılan düğümler, baştan yapılan sistemler) ve kendine ait özel resmi dokümantasyonu vardır.