0.1.0 Ne Anlama Gelir? Yazılımda Sürüm Numaralandırma Standartları: SemVer, CalVer ve ZeroVer Rehberi

Bir projeye yeni bir paket kurarken package.json, composer.json veya pyproject.toml dosyasında gördüğün 1.4.2, 0.1.0 ya da 24.04 gibi sayıların geliştirici tarafından rastgele seçildiğini düşünüyorsan büyük bir yanılgı içindesin.

Yazılım mühendisliğinde sürüm (versiyon) numarası bir etiket değil; o kütüphaneyi yazan geliştirici ile onu canlı (production) sisteminde kullanan binlerce mühendis arasında imzalanmış teknik bir sözleşmedir (contract). Bu sözleşmenin kurallarını bilmemek, masum görünen tek bir npm update komutuyla canlıdaki tüm sistemini çökertmene neden olabilir.

Gelin yazılım dünyasını yöneten 4 temel sürüm numaralandırma standardını ve kaputun altındaki kuralları inceleyelim.

1. SemVer (Semantic Versioning): MAJOR.MINOR.PATCH

GitHub kurucu ortaklarından Tom Preston-Werner tarafından standartlaştırılan SemVer 2.0.0 (Anlamsal Versiyonlama), bugün dünyadaki açık kaynak kütüphanelerin yaklaşık %90'ı tarafından kullanılır.

SemVer'de her sürüm numarası noktalarla ayrılmış 3 basamaktan oluşur: MAJOR.MINOR.PATCH (Örneğin: 2.4.1).

   2   .   4   .   1
   │       │       └── PATCH (Yama): Geriye uyumlu hata düzeltmeleri ve güvenlik yamaları
   │       └────────── MINOR (Özellik): Geriye uyumlu yeni özellik eklemeleri
   └────────────────── MAJOR (Kırılma): Breaking Change! Geriye dönük uyumluluğu bozan değişiklikler

Basamaklar Neye Göre Artar?

1. PATCH (2.4.1 ➔ 2.4.2): Sadece mevcut bir hatayı (bugfix) düzelttiğinde veya dış API davranışını değiştirmeyen bir güvenlik/performans yaması yaptığında artar. Gözün kapalı güncelleyebilirsin.
2. MINOR (2.4.2 ➔ 2.5.0): Kütüphaneye yeni bir fonksiyon veya özellik eklediğinde ama eski fonksiyonları kullanan kodların bozulmadığını garanti ettiğinde artar. (MINOR arttığında PATCH basamağı sıfırlanır).
3. MAJOR (2.5.0 ➔ 3.0.0): Tehlike çanıdır! Breaking Change (Kırıcı Değişiklik) anlamına gelir. Bir fonksiyonun adı değişmiş, aldığı parametreler silinmiş veya döndürdüğü veri yapısı farklılaşmıştır. MAJOR sürüm geçişlerinde kodunu değiştirmeden güncelleme yaparsan sistemin kırılır.

2. ZeroVer (0.1.0 Ne Anlama Gelir?)

Yeni çıkan kütüphanelerde veya araçlarda sıkça 0.1.0, 0.4.2 hatta yıllardır sıfırda kalan 0.29.0 gibi sürümler görürüz. Peki neden 1.0.0 değil de 0.1.0?

Resmi SemVer 2.0.0 spesifikasyonunun 4. maddesi bunu çok net tanımlar:

"Sıfır ile başlayan majör sürümler (0.y.z) başlangıç geliştirme aşaması içindir. Her an her şey değişebilir. Public API stabil kabul edilmemelidir."

Yani bir paketin sürümü 0 ile başlıyorsa (yazılım kültüründe buna ZeroVer denir), geliştirici sana açıkça şunu söylüyordur: "Bu kütüphane henüz resmi olarak stabil sözü vermiyor; yarın 0.1.0'dan 0.2.0'a geçerken tüm mimariyi değiştirebilirim, canlı sistemde kullanırken sorumluluk sende!"

3. CalVer (Calendar Versioning): Takvim Bazlı Versiyonlama

Her yazılım SemVer kalıbına sığmaz. İşletim sistemleri, tarayıcılar veya devasa IDE'ler tek bir fonksiyon sözleşmesinden ziyade zaman içinde sürekli evrilen ekosistemlerdir. Bu projeler CalVer (Takvim Versiyonlaması) kullanır:

• Ubuntu Linux (24.04 LTS): Buradaki 24 yılı (2024), 04 ise ayı (Nisan) temsil eder. Sadece sürüm numarasına bakarak sistemin ne zaman çıktığını ve 5 yıllık LTS desteğinin ne zaman biteceğini (Nisan 2029) saniyesinde anlarsın.
• JetBrains IDE'leri (2026.2): 2026 yılının 2. büyük güncellemesini ifade eder.
• Ubuntu, Pip, Certbot, Sentry: Kullanıcının elindeki aracın ne kadar güncel olduğunu tarih üzerinden okuması çok daha pratiktir.

4. Git Commit Hash Versioning (Modern CI/CD ve Mikroservisler)

Peki kendi şirketin içinde geliştirdiğin ve günde 15 kez canlıya (deploy) aldığın bir backend API'sine veya frontend uygulamasına her seferinde 1.0.14, 1.0.15 diye elle numara vermek mantıklı mı? Hayır.

Eğer dışarıya açık bir paket (npm/NuGet/PyPI kütüphanesi) yayınlamıyorsan, modern DevOps ve CI/CD boru hatlarında sürüm numarası olarak doğrudan Git Commit SHA (Özet Değeri) veya Tarih + Commit Hash birleşimi kullanılır:

# CI/CD hattında Docker imajını Tarih + Git Commit Hash ile etiketlemek
GIT_SHA=$(git rev-parse --short HEAD)
VERSION_TAG="2026.10.25-${GIT_SHA}"
 
docker build -t registry.czay.dev/checkout-api:${VERSION_TAG} .

Bu yaklaşımın en büyük avantajı izlenebilirliktir (traceability): Gece saat 03:00'te canlıdaki 2026.10.25-a4b8c1f sürümünde bir hata patladığında, "Acaba bu sürümde hangi kod vardı?" diye aramazsın; terminalde git show a4b8c1f yazıp hataya sebep olan satırı 2 saniyede bulursun.

Özet: Hangi Projede Hangisini Seçmelisin?

İlgili Kısa Video & Kaynaklar

Bu konuyu 60 saniyede özetlediğim kısa videoyu aşağıdan izleyebilir, Git ve sürüm kontrol süreçlerin için interaktif rehberimize göz atabilirsin:

• 🎬 YouTube Shorts: 0.1.0 Ne Anlama Gelir? (SemVer & CalVer)
• 📘 Git Temelleri: Sürüm Kontrolüne Giriş ve Pratik Kullanım Rehberi