Anlamsal Sürümleme (Semantic Versioning)
Semantik kelimesinin TDK karşılığı anlam bilimi, anlam bilimsel olarak düzenlenmiştir. Konuyla pek ilgisi yok. Ben merak ettim baktım ve sizle de paylaşmak istedim. Asıl konuya giriş yapacak olursak yazılım yönetimi dünyasında “Dependecy Hell” adında korkulu bir nokta vardır. Sistem büyüdükçe, kod geliştikçe büyük ihtimalle bir gün gelecek ki kendimizi çaresizliğin ortasında bulacağız. Flashback oldun mu? Evet evet o projeler…
Geliştirdiğimiz projelerin versiyon takibi yapmak için belirli yöntemler kullanmaktayız. Yazılımları versiyonlama yani versiyon numaraları atama işleminde dünya çapındaki bütün yazılımcıların belirli standartları bulunmaktadır. Bu standartlar Semantic Versioning başlığı altında Semantic Versioning (SemVer) adresinde paylaşılmaktadır. Daha çok API’leri (Uygulama programlama arayüzü) baz alan bir içeriğe sahip olmasına rağmen genel olarak yazılım versiyonlama işlemlerinde bizim için pusula niteliğinde olacaktır. Eğer projemizi versiyonlamaya karar verdiysek semver sitesinden kesinlikle faydalanmalıyız.
Olmadan olmaz mı? Yani versiyonlamadan olmaz mı? Olur da yarım olur, eksik olur, efendime söyleyeyim daha güzeli varken yoksun kalmak olur, olur da olur.. Çünkü asıl mesele son kullanıcı değil de sen, ben yani yazılımcılar. Versiyonlama ile projenin gelişimini çok daha rahat takip edebiliriz. Öyle ki, neredeeen nereye demenin binbir farklı bir yolundan biri.
Semantic Versioning (SemVer) versiyon numaraları temelde (temel de diyorum çünkü ufak bir durum var ve birazdan bahsedeceğim.) 3 parçadan oluşmaktadır. [MAJOR . MINOR . PATCH]
Büyüklük ilişkisi olarak: MAJOR > MINOR > PATCH
MAJOR: Yazılımın, eski versiyonlarında desteklenmeyen yeni özellikleri veya kaldırılan özellikleri barındırmasından ötürü büyük değişiklikleri temsil eder.
MINOR: Yazılımın, eski versiyonları da destekleyecek şekilde değişikliklerin olduğunu ifade eder.
PATCH: Adından da anlaşılacağı üzere yama diyebiliriz. Yama’dan kasıt bugfix veya diğer basit ve küçük değişikliklerdir. Kilit nokta, herhangi bir yeni özellik barındırmaz ya da var olan bir özelliği kaldırıldığı anlamına gelmez.
Bu 3 kısım (major, minör, patch) haricinde opsiyonel olarak dördüncü bir kısım daha bulunur. Genellikle release, beta sürümlerinde kullanılır.
İyi Hoş Ama Nasıl? (gerçek hayat )
LTunesTribe adında uygulamanız var ve uygulamanızın ilk versiyonunu 5.0.0 olarak belirlediniz. Uygulama özelinde;
Patch >> Kayıt olma ekranında bulunan email inputu doğrulamasındaki hatayı çözdüysek, bu patch’i ifade eder ve sadece patch kısmını bir attırmalıyız. O halde uygulamanın yeni versiyonu 5.0.1 olur.
Minör >> Uygulamaya sosyal login işlemlerini eklersek ve bu değişiklik eski sürüm kullanan kullanıcıları etkilemeyecek bir değişiklik olacaksa (eski sürümü kullanan kullanıcı da uygulamayı kullanmaya devam edebilecek olduğu anlamına gelir.) minör kısmını bir arttırırız. Bu durumda uygulamanın yeni versiyonu 5.1.0 olur.
Major >> Uygulamada var olan özelliklerin birçoğunu tamamen değiştirdiysek ya da eski sürüm kullanıcılarını büyük derecede etkileyecek, onlara uygulamayı kullanamaz hale getirecek bir değişiklik yaptıysak bu major bir değişikliktir. Örneğin uygulamanın hali hazırda olan email ile giriş işlemini sonlandırıp cep numarası ile giriş sağlanacağını örnek olarak düşünebiliriz. Bu durumda uygulamanın yeni versiyonu major bir değişiklik olduğundan dolayı 6.0.0 şeklinde olur.
Her bir versiyon arttırımı kendi altındaki versiyon numaralarının sıfırlanmasına neden olur. Örneğin uygulamanın versiyon numarası 1.4.5 ve yeni bir major versiyon çıkacağız. O halde uygulamanın yeni versiyonu 2.4.5 değil, 2.0.0 şeklinde olacaktır. Yani major versiyonu arttırdığımız için minör ve patch değerleri sıfırlanacaktır. Çünkü major, minör ve patch’den büyüktür. Diğer yandan eğer ki uygulamanın versiyonu 1.4.5 iken minör bir arttırma gidersek bu sefer de patch değeri sıfırlanır. Uygulamanın yeni versiyonu 1.5.0 şeklinde güncellenir.
Git ile Versiyonlama
Git ile uygulamaların o an ki son commit edilmiş hallerini versiyon olarak işaretleyebiliriz. Söz konusu durumda iki versiyon türü bulunur. Annotated Tagging ve Lightweight Tagging.
Annotated Tagging
Atılan commit’i istediğimiz versiyon numarasıyla etiketlememizi sağlar. Dolasıyla etiket eklenirken dosyaların tamamı o versiyon numarası ile kaydedilir. [Dipnot: Normal şartlarda commitler sadece bir önceki commit ile aralarındaki farkı kaydeder.] Bütünlüğün kontrolü için bir checksum (sağlama toplamı) üretilir, etiketi oluşturan kişi ve tarih bilgileri de saklanır. Tabii talep edilirse bir etiket mesajı da eklenebilir.
git tag -a v3.6 -m '3.6 version released'
Lightweight Tagging
Bu etiketlemenin annotated tagging etiketleme türünden farkı; etiketi oluşturan kişi, tarih, checksum gibi detaylı bilgiler içermek yerine sadece commit’e yeni bir etiket eklemesidir.
git tag v1.4-lw
Peki, annotated tagging varken neden lightweight tagging kullanayım?
Annotated tagging; etiketi oluşturan kişiyle ilgili verileri sakladığı için çok daha önemlidir. Tavsiye edilen bu yöntemle etiketlenmiş versiyonların müşterilere yeni versiyon şeklinde sunulması yönündedir.
Lightweight Tagging; yazılım grupları içerisinde işaretleyip diğer geliştiriciler ile üzerinde tartışmak, fikir alışverişinde bulunmak istenilen commitlerde kullanılır. Örneğin attığımız commit ile beraber uygulamanın yeni versiyonunu çıkacağız fakat diğer takım arkadaşlarımızla da birtakım konuşmalar gerçekleştirmemiz gerekli. İşte bu senaryo da commit’i örneğin 2.3-lw veya 2.3-pre gibi etiketleyerek diğer takım arkadaşlarımızla paylaşabiliriz. Sonuca gelindiğinde ise annotated etiketi oluşturabiliriz.
