Anlamsal Versiyonlama (SemVer)

Anlamsal Versiyonlama (SemVer), yazılım sürümlerini MAJOR.MINOR.PATCH şeklinde numaralandırmak için yaygın olarak benimsenmiş bir kural setidir (örn. `2.4.1`); her bölüm belirli bir değişiklik türünü işaret eder: geriye dönük uyumsuz, kırıcı bir değişiklik yaptığınızda MAJOR'ı artırın; geriye dönük uyumlu yeni bir özellik eklediğinizde MINOR'ı artırın; geriye dönük uyumlu bir hata düzeltmesi yaptığınızda PATCH'i artırın. Buradaki tüm amaç, diğer geliştiricilerin (ve otomasyon araçlarının) bir değişiklik günlüğünü satır satır okumadan, sadece versiyon numarasından bir bağımlılığı güncellemenin riskini çıkarabilmesidir. AI/SaaS kuran ekipler için neden önemli: neredeyse tüm paket yöneticisi ekosistemi (npm, pip, Cargo) SemVer kurallarının üzerine inşa edilmiştir — bir `package.json` içinde `^2.4.1` olarak listelenen bağımlılık npm'e "herhangi bir 2.x.x sürümünü otomatik kurmak güvenlidir" der; bu tamamen paket yazarının SemVer'i doğru takip etmesine, yani minor veya patch güncellemesinin kodunuzu gerçekten bozmamasına dayanır. Yaygın kullanılan bir paket SemVer'i ihlal ettiğinde (kırıcı bir değişikliği minor sürüm olarak yayınladığında), ekosistem genelinde kaos yaşanabilir — dün yeşil olan CI pipeline'ları, tüketici projede hiçbir kod değişikliği olmadan, sadece otomatik güncellenen bir bağımlılığın sessizce uyması gereken bir sözleşmeyi ihlal etmesi yüzünden bugün başarısız olmaya başlar. Nasıl çalışır: bir projenin manifest dosyası, SemVer'in garantileriyle eşleşen operatörler kullanarak versiyon kısıtlamaları belirtir — `^2.4.1`, `2.4.1`'den başlayıp `3.0.0`'a kadar (dahil değil) herhangi bir sürüme izin verir (kırıcı olmayan her güncelleme); `~2.4.1` yalnızca `2.4.x` içindeki patch güncellemelerine izin verir; kesin bir sabitleme olan `2.4.1` ise hiçbir otomatik güncellemeye izin vermez. Paket yöneticileri, gerçekte kurulacak sürümü seçmek için bu kısıtlamaları registry'ye karşı çözer; otomatik bağımlılık güncelleme araçları (Dependabot, Renovate) da önerilen bir güncellemenin muhtemelen düşük riskli (patch/minor) mi yoksa daha yakından incelenmesi gereken (major) mi olduğuna karar vermek için aynı semantiği kullanır. Örnek üzerinden: bir ekip, `package.json` dosyasında popüler bir tarih işleme kütüphanesine `^3.2.0` olarak bağımlıdır. Kütüphanenin geliştiricileri yeni, opsiyonel bir fonksiyon ekleyen `3.3.0`'ı (güvenli, geriye dönük uyumlu — doğru şekilde MINOR artışı) ve ayrı olarak kullanımdan kaldırılmış bir fonksiyonu tamamen kaldıran `4.0.0`'ı (kırıcı değişiklik — doğru şekilde MAJOR artışı) yayınlar. `npm update` çalıştırmak otomatik olarak `3.3.0`'ı sıfır riskle çeker, çünkü `^3.2.0` kısıtlamasını karşılar ve SemVer aynı major sürüm içinde kırıcı değişiklik olmayacağını garanti eder — ama `4.0.0` bilerek dokunulmadan bırakılır; ekibin kısıtlamayı manuel güncellemesini ve kırıcı değişikliği kendi takviminde ele almasını gerektirir, tam olarak SemVer sözleşmesinin vaat ettiği gibi. Bu aynı zamanda "dependency confusion" hatalarının gerçekleştiğinde neden bu kadar yıkıcı olduğunu da açıklar — bir paket yazarının kırıcı bir değişikliği yanlışlıkla bir patch sürümü olarak yayınlaması, SemVer sözleşmesine güvenerek otomatik güncellenen binlerce alt projeyi sessizce bozabilir.