Mobil Uygulamada Sürüm Yönetimi: Semantic Versioning'den Kademeli Yayına

2.3.1 mi yazmalı, yoksa 2.4.0 mı? Bu soruyu geliştirme ekibinde gündeme getirdiğimde çoğu zaman "fark eder mi ki" tepkisi alıyorum. Fark ediyor, çünkü sürüm numarası sadece bir etiket değil, kullanıcıya ve destek ekibine ne tür bir değişiklik geldiğini anlatan bir dil.

Semantic versioning mantığı basit ama disiplin ister

Üç haneli sürüm numarası — major.minor.patch — her hanenin farklı bir anlamı olduğu bir sistem. Patch (2.3.1) küçük hata düzeltmeleri için, minor (2.4.0) geriye dönük uyumlu yeni özellikler için, major (3.0.0) ise köklü değişiklikler ya da eski sürümle uyumsuz güncellemeler için kullanılıyor. Bu ayrımı tutarlı uygulamak, hem destek ekibinin "hangi sürümde bu hata var" diye sorgulama yapmasını kolaylaştırıyor hem de otomatik derleme (CI/CD) süreçlerinde sürüm karşılaştırması yapan sistemlerin doğru çalışmasını sağlıyor. Android'de versionCode her yayında artan tam sayı olmalı, versionName ise kullanıcıya görünen semantic versiyon; bu ikisini karıştırmak Play Console'da yayın reddine yol açabiliyor.

Zorunlu güncelleme ne zaman gerekiyor

Her güncellemeyi zorunlu kılmak kullanıcıyı yorar, hiçbirini zorunlu kılmamak ise güvenlik açığı olan ya da API uyumsuzluğu yaratan eski sürümlerin uzun süre kullanılmasına yol açar. Bizim uyguladığımız mantık şu: backend'de kırıcı bir API değişikliği yapıldığında ya da kritik bir güvenlik açığı kapatıldığında zorunlu güncelleme tetiklenir. Bu genelde uygulama açılışında sunucudan çekilen bir "minimum desteklenen sürüm" bilgisiyle kontrol edilir; kullanıcının sürümü bu eşiğin altındaysa güncelleme ekranı gösterilir ve uygulama kullanıma kapatılır. Kozmetik değişiklikler ya da küçük iyileştirmeler için zorunlu güncelleme kullanmak gereksiz sürtünme yaratıyor.

Kademeli yayın riski azaltıyor

Yeni bir sürümü tüm kullanıcılara aynı anda açmak, gizli bir hatanın herkesi aynı anda etkilemesi riskini taşıyor. Google Play Console ve App Store Connect, kademeli yayın (staged rollout) özelliği sunuyor: yeni sürüm önce kullanıcıların %5-10'una açılıyor, crash-free oranı ve kullanıcı yorumları izlenip sorun görülmezse oran kademeli olarak artırılıyor. Android uygulama geliştirme projelerinde bu özellik Play Console'da doğrudan mevcut ve kullanılmaması için hiçbir sebep yok; ciddi bir hata büyük kitleye ulaşmadan durdurulabiliyor.

iOS tarafında süreç biraz daha yavaş işliyor

iOS uygulama geliştirme sürecinde App Store'un inceleme süresi — genelde 24-48 saat, bazen daha uzun — sürüm stratejisini doğrudan etkiliyor. Acil bir hata düzeltmesi gerektiğinde bu inceleme süresi beklenmeden kullanıcıya ulaşmak mümkün değil, bu yüzden kritik hataları önlemek için TestFlight'ta daha geniş bir beta test grubu tutmak, App Store'a çıkmadan önce sorunları yakalamanın en pratik yolu. Apple'ın kendi kademeli yayın özelliği de var (phased release), 7 gün boyunca kullanıcı yüzdesini otomatik artırıyor ama Android kadar esnek manuel kontrol sunmuyor.

Değişiklik notları küçümsenmemeli

"Hata düzeltmeleri ve performans iyileştirmeleri" yazan sürüm notları hem kullanıcıyı hem destek ekibini bilgisiz bırakıyor. Gerçekte ne değiştiğini birkaç maddeyle yazmak, hem mağaza sayfasında güven verici duruyor hem de bir sorun bildirildiğinde "bu son sürümde mi düzeldi" sorusuna hızlı cevap vermeyi sağlıyor. Küçük bir detay gibi görünse de sürüm geçmişini düzenli tutan uygulamalar, kullanıcı desteği tarafında zaman kazandırıyor.

Güncelleme Kademeli Yayın Mobil Uygulama Semantic Versioning Sürüm Yönetimi