Semantik Sürüm Oluşturma (SemVer) Nedir?

Yazılım sürümü belirlemenin herhangi bir standardının bulunmaması, yazılım geliştiriciler ve tüketiciler için hiçbir fayda sağlamaz; hatta yanlış yönlendirmelerle zarar bile verebilir. Ben bir yazılım üretip sürümün adını elma ya da üzerinde çok çalışıldığını düşündürmek için direkt yüksekten başlatarak 6.2 koyabilirim. Bu konuda yazılım geliştiriciyi kısıtlayan, uyulması zorunlu olan herhangi bir kural bulunmamaktadır.

Ancak de facto standardı dediğimiz, bir yasa ile denetimi sağlanmamasına rağmen toplum tarafından kabul edilen doğrulardan, semantik sürüm oluşturma bu konuda gerekli kısıtlamaları sağlıyor.

Yazılımda bir versiyondan diğerine geçişte geliştirici ve faydalananlar için belli başlı riskler bulunmaktadır. En önemli risklerin başında, hali hazırda yazılımdan faydalananların yeni sürüme uyum sağlayıp sağlayamayacağı gelir.

Eğer yazılım geliştirici semantik sürüm oluşturma standartlarını kullanırsa, yeni versiyonda kullanıcıyı ne beklediğine dair gerekli ipuçlarını verecektir. Örneğin, sürüm adı 1.2.5'ten 2.0.0'a geçiş yapıyorsa, eski sürümde yazılan kodlar yeni sürümle uyumlu olmayabilir. En baştaki sayının artmasıyla geriye uyumluluğun kaybolduğunun farkına varan, semantik sürüm oluşturma hakkında bilgisi olan kullanıcılar, gerekli kontrolleri yapacaktır.

Semantik sürüm oluşturma standardı ilk olarak Tim Preston-Werner tarafından, hem yazılım sürümlerindeki karmaşayı kaldırmak, hem de sürümlere az da olsa anlam yüklemek adına önerildi.

Faydalarını özetlemek gerekirse,

• Yazılım sürüm değişikliğiyle ilgili ipuçları verir.
• Sürümlerin geriye uyumlu olup olmadığını belirtir.
• Paket yönetim sistemleriyle arzu edilen sürüm aralığı belirlenebilir.

Semantik sürüm formatı, noktalarla ayrılmış üç sayı şeklindedir. Üç sayı da farklı anlam ifade eder.

major.minor.patch

Yani semantik sürüm standartlarını kullanan bir yazılıma bir yama (patch) geldiğinde sağdaki sayı, geriye uyumluluğu bozmayan yeni bir fonksiyonalite (minor) eklendiğinde ortadaki sayı, geriye uyumluluğun kaybolmasını sağlayan büyük bir güncelleme (major) geldiğinde ise soldaki sayı bir arttırılır.

v0.1.0 // Yeni proje
v0.2.0 // Yeni işlevsellik
v0.2.1 // Hata düzeltme
v0.3.0 // Yeni işlevsellik
v0.3.1 // Hata düzeltme
v0.3.2 // Hata düzeltme
v0.3.3 // Hata düzeltme
v0.3.4 // Hata düzeltme
v0.4.0 // Yeni işlevsellik
v0.4.1 // Hata düzeltme
v0.4.2 // Hata düzeltme
v1.0.0 // Üretim ortamı
v1.1.0 // Yeni işlevsellik
v1.2.0 // Yeni işlevsellik
v1.2.1 // Hata düzeltme
v2.0.0 // Geriye uyumluluğun yitirilmesini sağlayan güncelleme
...

Paket yönetim sistemlerinde sürümlerin dağıtım ve edinme süreci otomasyona sokularak kolaylaştırılır. Örneğin, bir paketin kullanılan sürümden itibaren, geriye uyumluluğu kaybettirmeyen tüm sürümlerini projeye dahil etmek için paket sürümünün ^x.x.x şeklinde tanımlanması yeterli olacaktır.

Npm'in internet sitesinden alınan sürüm aralığı belirleme yöntemleri:

• versiyon - Yalnızca versiyon ile eşleşen sürümü kabul eder.
• ~versiyon - versiyondan itibaren yalnızca yama sürümlerini kabul eder. 1.2.x ile aynıdır.
• ^versiyon - versiyondan itibaren yama ve yeni fonksiyonalite sürümlerini kabul eder. 1.x.x ile aynıdır.
• >versiyon - versiyondan daha yüksek sürümleri kabul eder.
• >=versiyon - versiyona eşit veya daha yüksek sürümleri kabul eder.
• <=versiyon - versiyona eşit veya daha düşük sürümleri kabul eder.
• <versiyon - versiyondan daha düşük sürümleri kabul eder.
• * - Her sürümü kabul eder.
• versiyon1 - versiyon2 - versiyon1e eşit veya büyük ve versiyon2ye eşit veya küçük sürümleri kabul eder.

{
  "name": "projectName",
  "version": "0.1.0",
  "dependencies": {
      "bootstrap": "^4.0.0", // 4.x.x ile aynı
      "jquery": "~3.3.1" // 3.3.x ile aynı
  }
}