Mevcut çalışan sürümü ve yükseltme nedenini kaydedin
React Native yükseltme kapsamı başlamadan önce framework, React, Node, paket yöneticisi, Android ve iOS araç sürümlerini kaydedin. Depodaki lockfile ile geliştiricinin kurduğu paketler aynı olmayabilir. Son çalışan commit, release paketi ve derleme tarifi referans olmalıdır. Mevcut sürüm temiz bir ortamda derlenemiyorsa bu bulgu yeni yükseltmeden önce görünür hale getirilir.
Yükseltme nedenini belirli yazın: desteklenmeyen bağımlılık, gerekli platform uyumluluğu veya doğrulanmış hata gibi. “En yenisi” tek başına kabul ölçütü değildir. Hedef sürüm seçilirken release notları ve kritik modüllerin desteği birlikte değerlendirilir. Mevcut hataları başlangıç kaydında ayırın; eski bir kamera hatasını sonradan yeni sürümün etkisi gibi göstermeyin. Önce ve sonra sonuçlarını aynı görev, cihaz ve veriyle karşılaştıracağınız test planını hazırlayın.
Bağımlılıkları ve native modülleri ayrı inceleyin
Mobil uygulama envanterinde gezinme, animasyon, depolama, kamera, bildirim, ödeme ve özel native kodu listeleyin. Doğrudan kullanılan paket kadar onun getirdiği bağımlılık da derlemeyi etkileyebilir. Her kritik modülün hedef framework ve mimariyle uyumunu kendi sürüm notundan kontrol edin. Bakımı durmuş veya özel yama gerektiren bir modül için alternatif ve kapsam kararı gerekir.
Android'in Türkçe bağımlılık yükseltme rehberi risk analizi ve araç uyumluluğunu vurgular. Paket sürümü, gerekçe, yapılan kod değişikliği ve doğrulanan cihaz işlevini değişiklik kaydına yazın. Bir modülü kaldırmak ekrandaki özelliği de etkiliyorsa ürün sahibi karar verir. Yerel patch dosyalarını ve özelleştirilmiş native projeleri atlamayın; paket kurulumu başarılı olduğunda bu özel davranışların taşındığı kanıtlanmış olmaz.
| Bağımlılık | Uyumluluk kanıtı | Kabul testi |
|---|---|---|
| Kamera modülü | Kendi sürüm notu ve native destek | İzin reddi, çekim, uygulamaya dönüş |
| Bildirim SDKsi | Hedef platform ve SDK gereksinimi | Ön/arka plan ve bağlantı açma |
| Özel native kod | Değişen proje dosyası incelemesi | Gerçek cihazdaki görev sonucu |
OKUMADAN SONRAKİ ADIMA
Yükseltmenin kapsamını değerlendirelim
Mevcut sürüm, bağımlılıklar ve derleme sorunlarıyla başlayın.
Şablon farklarını inceleyip değişikliği bölün
Tekrar üretilebilir derleme süreci yükseltmenin hangi noktada bozulduğunu anlamayı kolaylaştırır. React Native'in resmî yükseltme belgesi proje dosyalarını ve sürüm farklarını ele alır. Upgrade Helper, başlangıç ve hedef sürümün şablon farklarını görmenize yardımcı olur; uygulamanızın bütün özel kodunu otomatik doğrulamaz. Farkları kör biçimde üzerine yazmayın.
İlgili framework, araç zinciri ve zorunlu bağımlılık değişikliklerini anlamlı adımlara ayırın. Her ara adımın derleme ve temel akış sonucu kayıtlı olsun. Bütün paketleri, arayüzü ve ürün işlevlerini aynı değişikliğe eklemek nedeni bulmayı zorlaştırır. Büyük sürüm aralığında hangi ara durakların gerekli olduğu uyumluluğa göre belirlenir; her sürümü zorunlu geçirmek gibi evrensel bir reçete kullanmayın. Deneme dalı veya ayrı çalışma alanı eski çalışan tabanı korumalıdır.
Ekranları ve cihaz işlevlerini release paketinde sınayın
Uygulama davranışı incelemesi için giriş, liste, detay, form ve ana dönüşüm görevlerini yeniden çalıştırın. Font, boşluk, klavye, güvenli alan, Android geri tuşu ve modal kapanışı küçük sürüm değişimlerinde de etkilenebilir. Ekran görüntüsü karşılaştırması tek başına dokunma hedefinin, odak sırasının veya hata mesajının doğru çalıştığını göstermez.
Kamera, bildirim, konum ve dosya işlemlerini gerçekten desteklenen cihazlarda test edin. İzin reddedilmişken, uygulama arka plandayken ve ağ kesilmişken davranışı kaydedin. Debug ile release paketleri farklı sonuç verebilir; mağaza adayını ayrıca sınayın. Temiz kurulumun yanında önceki uygulamadan güncelleme yaparak yerel verinin ve oturumun durumunu kontrol edin. Test edilmemiş platform veya cihaz sınıfı varsa bunu kapsam sınırı olarak yazın.
Ekran regresyonu
Aynı görev ve veriyle görsel düzen, etkileşim ve hata davranışı karşılaştırılır. Bulgunun ekranı, cihazı ve sürümü kayda girer.
Cihaz regresyonu
Native işlev, izin durumu ve yaşam döngüsü birlikte sınanır. Modül değiştiğinde ilgili cihaz akışı yeniden test edilir; yalnızca başarılı derleme yeterli değildir.
Performansı aynı koşullarda karşılaştırın
Performans karşılaştırmasında eski ve yeni release paketleri için cihaz, veri hacmi, ağ koşulu ve görev aynı tutulmalıdır. Başlangıç süresi, uzun liste kaydırma veya bellek davranışı projenin gerçek sorununa göre seçilir. Tek bir hızlı denemeyi genel iyileşme sonucu olarak sunmayın. Isınmış uygulama ile soğuk açılışın farklı ölçümler olduğunu raporda belirtin.
Ölçümü kim yapacak, hangi yöntem kullanılacak ve hangi fark kabul edilecek önceden yazın. Ekran takılması veya çökme gibi gözlenebilir bulguları nicel sonuçtan ayrı kaydedin. Yeni sürümde iyileşen bir görev başka görevdeki bozulmayı gizlememelidir. Kullanıcı verisi içeren profil kayıtları paylaşılmadan temizlenir. Uygulamanızda ölçüm yapılmadıysa yükseltmeyi “performans optimizasyonu tamamlandı” diye adlandırmayın; performans karşılaştırmasını bekleyen iş olarak tutun.
Paket değişikliklerini ve yayın kabulünü tamamlayın
Yükseltme tesliminde eski/yeni sürümler, çıkarılan modüller, özel yamalar, bilinen sınırlamalar ve tekrarlanabilir derleme adımları bulunmalıdır. Geliştirme ekibinin yerel testi ile mağaza adayı paketinin doğrulamasını ayrı gösterin. Açık bulguların hangisi yayın engeli, hangisi koşullu kabul olduğunu ürün sahibi ve teknik sorumlu birlikte kararlaştırır.
Yayın planında artefakt kimliği, test kanalı, sorumlu ve gözlem tarihi yer alır. Eski istemcilerle sunucu uyumluluğunu koruyun; depolama biçimi değiştiyse veri toparlanmasını ayrıca değerlendirin. Mağaza dağıtımından sonra önceki pakete her cihazda anında dönülebileceğini varsaymayın. Düzeltme sürümü ve dağıtımı durdurma kararı hazırlanmalıdır. Her eksik için kanıt, sahip ve yeniden test sonucu kullanın; hedef sürüme ulaşmak tek başına tamamlanmış teslim değildir.
Kontrol listesini al ve kapsamını değerlendir
E-posta ve telefon bu taleple ilgili iletişim içindir. Bülten aboneliği oluşturmaz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Hangi hedef sürüm seçilmeli?
Projenin ihtiyaç duyduğu platform desteği, mevcut sürüm aralığı ve kritik bağımlılıkların uyumu birlikte değerlendirilir. Sadece en yeni numarayı seçmeyin. Güncel resmî sürüm notlarını inceleyin ve seçimin gerekçesini kabul kaydına yazın.
Her ara sürümden geçmek gerekli mi?
Evrensel bir kural değildir. Değişikliklerin büyüklüğü, native dosyalar ve kütüphane uyumluluğu planı belirler. Ara adımlar sorunu ayırmayı kolaylaştırabilir. Gereken adımları kanıta göre seçin; kullanılan eski komutları güncel belgeyle doğrulayın.
Upgrade Helper her şeyi otomatik yapar mı?
Hayır. Şablon dosyaları arasındaki farkları gösterir ve incelemeye yardımcı olur. Uygulamadaki özel native kodu, modül davranışını, veriyi ve bütün kullanıcı görevlerini doğrulamaz. Farkları uyguladıktan sonra derleme ve cihaz kabulü gerekir.
Derleme başarılıysa yükseltme bitti mi?
Hayır. Oturum, izin, bildirim, kamera, yerel veri ve release davranışı ayrıca sınanır. Temiz kurulum ile eski sürümden güncelleme farklı testlerdir. Başarılı derlemenin hangi paket ve platforma ait olduğunu kaydedin.
Yükseltme performansı artırır mı?
Bu, uygulamanızda ölçülmelidir. Aynı cihaz ve görevle önce/sonra karşılaştırma yapmadan hız artışı iddia etmeyin. Asıl amaç uyumluluk veya bakım olabilir. Performans etkisi ayrı kabul ölçütleri ve gerçek gözlemlerle değerlendirilir.
KAPSAMI BİRLİKTE BELİRLEYELİM
Yükseltmenin kapsamını değerlendirelim
Mevcut sürüm, bağımlılıklar ve derleme sorunlarıyla başlayın.
Yükseltme kapsamını görüş