Bir uygulamayı güncellediğinizde telefonunuzda "2.4.1" gibi bir ibare görürsünüz. Oysa o güncellemenin arka planında, sistemin tanıdığı tamamen farklı bir sayı daha vardır: sürüm kodu. Bu iki kavram birbirine benzer görünse de amaçları, muhatapları ve işleyiş biçimleri tamamen farklıdır. Bu yazıda sürüm kodu (version code) ile sürüm adı (version name) arasındaki farkları, bunların neden ayrı ayrı var olduğunu ve farklı platformlarda nasıl uygulandığını ele alıyoruz.
Bir bakışta
- Sürüm kodu sistemlerin güncelleme kontrolü için kullandığı tamsayı değer, sürüm adı ise kullanıcıya görünen metinsel ifadedir.
- Semantik versiyonlamada BÜYÜK.KÜÇÜK.YAMA yapısı kullanılır ve her bölümün değişikliğin türünü gösteren belirli anlamı vardır.
- Android, iOS, masaüstü ve web uygulamalarında benzer ayrım olsa da platform ve adlandırma farklılıkları mevcuttur.
Sürüm Kodu ve Sürüm Adı: Temel Tanımlar
Sürüm kodu, bir yazılımın hangi sürümünün diğerinden daha yeni olduğunu sistemlerin anlayabilmesi için kullanılan, genellikle tamsayı biçiminde tutulan teknik bir değerdir. Bu değer kullanıcıya gösterilmez; işletim sistemi, uygulama mağazası ya da güncelleme mekanizması tarafından arka planda karşılaştırma yapmak için kullanılır.
Sürüm adı ise kullanıcının ekranda gördüğü, genellikle "1.0", "2.4.1" gibi noktalarla ayrılmış veya bazen tamamen isimlendirilmiş (örneğin bir kod adı) metinsel ifadedir. Amacı, değişikliğin büyüklüğünü ve niteliğini insana anlaşılır şekilde aktarmaktır.
İki ayrı sistemin var olmasının temel nedeni, makinelerin ve insanların farklı ihtiyaçları olmasıdır. Bir sistem için önemli olan "hangi sürüm daha yeni" sorusuna kesin ve hatasız cevap verebilmektir; bu da basit, artan bir sayı ile en güvenilir şekilde sağlanır. İnsan içinse önemli olan sürümün ne getirdiği, ne kadar büyük bir değişiklik olduğu hakkında hızlı bir izlenim edinmektir. Bu nedenle yazılım geliştirme süreçlerinde genellikle bu iki değer paralel olarak, ancak birbirinden bağımsız şekilde yönetilir.
Sürüm Kodunun Özellikleri ve İşlevi
Sürüm kodu tasarım gereği sade tutulur: çoğunlukla her yeni sürümde bir artan tamsayıdır (1, 2, 3…). Bu sadelik bilinçli bir tercihtir; çünkü bir sistemin iki sürümü karşılaştırırken "2.10" ile "2.9" gibi noktalı ifadeleri doğru sıralaması bazen karmaşık kurallar gerektirirken, düz bir tamsayı karşılaştırması her zaman tutarlı sonuç verir.
Bu özelliklerden dolayı sürüm kodu, güncelleme yönetiminde kritik bir rol oynar. Bir cihaz ya da uygulama mağazası, yüklü sürümün kodu ile sunucudaki en güncel sürümün kodunu karşılaştırarak güncelleme gerekip gerekmediğine karar verir. Bu karşılaştırma kullanıcıya hiç gösterilmeden, tamamen otomatik şekilde gerçekleşir.
Sürüm kodu platformdan bağımsız bir kavram olsa da her platformda farklı isimlerle anılabilir (version code, build number, internal version gibi). Ortak nokta, bunun insanlara değil sistemlere hitap eden bir değer olmasıdır.
Sürüm Adının Özellikleri ve İşlevi
Sürüm adı, insan tarafından okunabilir ve anlamlandırılabilir olacak şekilde tasarlanır. Bu amaçla en yaygın kullanılan yapı semantik versiyonlamadır (semantic versioning): BÜYÜK.KÜÇÜK.YAMA biçiminde üç bölümden oluşan bu sistemde her bölümün belirli bir anlamı vardır. Büyük sürüm numarasının artması genellikle köklü değişiklikleri, küçük sürüm numarasının artması yeni özellikleri, yama numarasının artması ise hata düzeltmelerini işaret eder.
Bu yapı sayesinde bir kullanıcı veya geliştirici, sürüm adına bakarak değişikliğin kabaca ne ölçekte olduğu hakkında fikir sahibi olabilir. Örneğin "3.0.0"dan "4.0.0"a geçiş, "3.1.2"den "3.1.3"e geçişten çok daha büyük bir değişikliği ima eder.
Sürüm adı aynı zamanda pazarlama ve iletişim amacıyla da kullanılır. Bazı yazılımlar sürüm adlarına ek olarak kod adları (bir dönem ya da tema ile ilişkili isimler) ekleyebilir; bu, tamamen kullanıcı deneyimini ve markalaşmayı güçlendirmeye yönelik bir tercihtir ve teknik karşılaştırma mantığıyla ilgisi yoktur.
Mobil Platformlarda (Android, iOS) Uygulanış
Android'de bu ayrım oldukça nettir: versionCode adlı tamsayı değer, sistemin ve Play Store'un güncelleme kontrolü yaptığı değerdir; versionName ise kullanıcıya gösterilen, geliştiricinin istediği biçimde (genellikle semantik versiyonlama formatında) belirlediği metindir. Bir geliştirici versionName olarak "2.1" yazarken versionCode olarak 14 gibi bir sayı kullanabilir; kullanıcı hiçbir zaman 14 sayısını görmez.
iOS ekosisteminde kavramlar farklı adlarla ama benzer mantıkla var olur: "build number" sistemin ve App Store'un sürüm ayrımı için kullandığı değerken, "version number" (örneğin "1.4.2") kullanıcıya gösterilen sürüm bilgisidir. Build number her yüklemede artırılması gereken bir sayı iken, version number genellikle yalnızca kullanıcıya anlamlı değişiklik olduğunda güncellenir.
Her iki platformda da mağaza, aynı görünür sürüm adına sahip iki farklı derlemeyi birbirinden ayırt edebilmek için bu iç koda ihtiyaç duyar; bu, test sürümleri ve küçük düzeltme paketleri yayımlanırken özellikle önemlidir.
Masaüstü ve Web Uygulamalarında Uygulanış
Masaüstü yazılımlarında da benzer bir ayrım gözlemlenir, ancak platforma göre isimlendirme ve uygulama şekli değişebilir. Windows yazılımlarında dört parçalı sürüm numaraları (Major.Minor.Build.Revision) kullanılabilir; burada build ve revision kısımları daha çok iç takip amacıyla kullanılırken, kullanıcıya genellikle yalnızca ilk iki veya üç kısım gösterilir.
Linux ve açık kaynak projelerinde sürüm yönetimi genellikle sürüm kontrol sistemleri (Git gibi) üzerinden etiketlerle (tag) yürütülür. Bu projelerde "sürüm kodu" kavramı daha çok commit hash'leri veya build numaraları şeklinde var olabilirken, kullanıcıya gösterilen sürüm adı genellikle semantik versiyonlamaya dayanır.
Web uygulamalarında, uygulama doğrudan sunucuda güncellendiği için klasik anlamda bir "sürüm kodu – mağaza karşılaştırması" döngüsüne çoğu zaman ihtiyaç yoktur. Yine de iç takip için build numaraları kullanılabilir; kullanıcıya gösterilen sürüm bilgisi ise genellikle sade bir semantik sürüm adıdır. Tarayıcı uzantılarında ise mağaza politikaları gereği genellikle noktalı sayısal sürüm adları zorunlu tutulur ve ayrı bir "kod" kavramı daha az belirgindir.
Gerçek Dünya Örnekleri
Pratikte, kullanıcıların gördüğü sürüm adı ile arka plandaki sürüm kodu arasında doğrudan bir ilişki olmayabilir. Örneğin bir uygulama, kullanıcıya "5.2.0" olarak görünse de bu sürümün arkasında, geliştirme sürecinde yayımlanmış onlarca test sürümüne karşılık gelen çok daha yüksek bir iç sürüm kodu bulunabilir. Kullanıcı bu ara sürümleri hiç görmez; yalnızca kararlı (stable) sürümün adı kendisine gösterilir.
Bazı durumlarda aynı sürüm adı, farklı cihaz veya bölgelerde farklı sürüm kodlarıyla dağıtılabilir. Bu genellikle cihaza özgü küçük düzeltmeler ya da kademeli dağıtım (staged rollout) süreçleriyle ilgilidir; kullanıcı açısından görünen isim aynı kalırken, sistemin takip ettiği iç değer farklılaşabilir.
Pazarlama tarafında ise bazı yazılım veya donanım üreticileri sürüm adlarına doğa, yer veya tema temelli kod adları ekleyerek kullanıcı algısını güçlendirmeyi tercih edebilir. Bu kod adları tamamen iletişim amaçlıdır ve sürüm kodunun sıralama mantığına hiçbir etkisi yoktur.
Sürüm Kontrolü ve Değişiklik Günlükleri İlişkisi
Sürüm kontrol sistemlerinde (örneğin Git tabanlı projelerde) genellikle etiketler (tag) kullanılarak belirli bir commit, bir sürüm adıyla ilişkilendirilir. Bu etiketler çoğunlukla insan tarafından anlaşılır sürüm adını (örneğin "v2.3.0") temel alır; iç sürüm kodu ise çoğu zaman yapı (build) sürecinde otomatik olarak üretilir ve doğrudan etiketlenmez.
Değişiklik günlükleri (changelog) yazılırken de muhatap insan olduğu için neredeyse her zaman sürüm adı esas alınır. Bir kullanıcı "Bu sürümde neler değişti?" sorusunu sorduğunda, cevap "sürüm kodu 142'de şunlar değişti" şeklinde değil, "2.3.0 sürümünde şunlar eklendi" şeklinde verilir. Sürüm kodu, bu günlüklerde yalnızca teknik destek veya hata ayıklama bağlamında, belirli bir derlemeyi kesin olarak tanımlamak gerektiğinde referans olarak kullanılabilir.
Bu durum, geliştirici ile kullanıcının farklı ihtiyaçlarının somut bir yansımasıdır: geliştirici ve sistemler kesinlik ve otomatik sıralama ister; kullanıcı ise anlam ve bağlam ister.
Pratik Sonuçlar ve Faydalar
Bu ayrımın en somut faydası otomatik güncelleme mekanizmalarının güvenilir çalışmasıdır. Sürüm kodu sayesinde bir sistem, kullanıcıya hiçbir açıklama yapmadan arka planda doğru sürümün yüklü olup olmadığını kesin olarak tespit edebilir. Sürüm adı tek başına kullanılsaydı, farklı biçimlendirme alışkanlıkları nedeniyle bu karşılaştırmalar hataya açık olabilirdi.
Kullanıcı iletişimi tarafında ise sürüm adının sade ve anlamlı olması, kullanıcıların güncellemeleri takip etmesini ve güncelleme notlarını anlamasını kolaylaştırır. Bir kullanıcı için "versionCode 187" ifadesinin hiçbir anlamı yoktur; ama "3.5 sürümü" ifadesi bir referans noktası sağlar.
Hata raporlama ve teknik destek süreçlerinde ise genellikle her iki bilgiye de ihtiyaç duyulur. Kullanıcı sürüm adını bildirirken, destek ekibi aynı sürüm adına sahip farklı derlemeleri ayırt edebilmek için sürüm koduna başvurabilir. Bu da versiyon yönetim süreçlerini sadeleştirirken, aynı zamanda teknik kesinliği korumuş olur.
Sonuç olarak sürüm kodu ve sürüm adı, aynı madalyonun iki farklı yüzüdür: biri makinelerin güvenilir çalışması için, diğeri insanların anlamlı iletişim kurabilmesi için tasarlanmıştır. Bu ayrımı anlamak, hem yazılım geliştirme süreçlerini hem de güncelleme ve sürüm takibiyle ilgili günlük karşılaşılan durumları daha net kavramaya yardımcı olur.
