Bu yazıda nereden geliyor diye merak ediyorsanız, o zaman birinci bölümü okumanızı tavsiye ederim: Go 1.11 ile gelen yeni Module özelliği — 1. Bölüm Module kavramını anlatmadan önce, Module ile ne çözülmek isteniyor sorusuna cevap verebilmek adına biraz genel…medium.com

Kaldığımız yerden devam edelim. Modules: beraberce versiyonlanan Go paketleri demekti. Çoğu zaman Git gibi repolarda sakladığınız kodların hepsine bir Module diyebiliriz, ama bir repo içinde birden fazla module de saklamak mümkün. Eğer başka dillerden geliyorsanız, mesela .NET gibi, bunu .csproj ile tanımlanan bir proje olarak düşünebilirsiniz.

Go modüllerini anlarken, bilinmesi gereken diğer kavram, semantic versiyonlama. Semantic manasal demek. Dolayısıyla, bir versiyonlama yaparken kullandığınız sayıların ve bu sayıların yerlerinin bir manası var. Bu numaralara bakan insanlar, hangi yerde ki hangi sayının ne manaya geldiğini ve dolayısıyla ne beklemeleri gerektiğini bilecekler demektir.

Aslında yukarıda ki resim bu versiyonlama biçimini gayet anlaşılır biçimde gösteriyor ama İngilizce bilmeyen arkadaşlar için kısaca özetlemek gerekirse:

4.2.1 diye versiyonladığınız — ki bu şekilde bir versiyonlama takip etmeniz gerekiyor — bir projede 4 büyük versiyon, 2 küçük versiyon, ve 1 ise yama versiyonu demek. Büyük versiyon ciddi değişiklerin olduğunu ve bir önceki sistemle ile çalışmayacağı manasına geliyor. Yani eğer versiyon 3'ü kullanıyorsanız, kendi kodunuzda hiç bir değişiklik yapmadan versiyon 4'ü büyük bir ihtimal kullanamayacaksınız demektir. Küçük versiyon ise, sadece yeni özelliklerin eklendiğini ama kodunuzu bozacak değişiklikler yapılmadığını söylüyor. Son olarakta yama, yani patch, ise hataların giderildiğini ve onun dışında başka değişiklikler yapılmadığını söylüyor.

Go da yeni module özelliği işte bu semantic versioning olayını kullanıyor. Onun için bilmek önemliydi. Ama universal bir şey olduğundan kendi projeleriniz de bu versiyonlama tekniğini kullanabilirsiniz. Hatta bence sorun değilse, kesinlikle kullanın.

Hatırlarsanız, Go da indirilen paketler src klasörü altında tutuluyordu ve herhangi bir versiyonlamaya tabi değillerdi. Dolayısıyla Go mümkün mertebe daha önce indirdiği paketleri ona ihtiyaç duyan tüm paket ve projelerde kullanıyordu. Bunun hakkında daha detaylı bilgiyi bir önceki makalemde bulabilirsiniz.

Yeni versiyonlama ile bu olay değişti. Diyelim ki aşağıda ki gibi bir dependency durumu mevcut:

MyApp 1.9 > MarsLib 2.1 > WorldLib 3.1

Sonrasında MyApp içinde kullanılmak üzere başka bir paket daha indirdiniz ve dependency aşağıda ki gibi gözükmeye başladı:

MyApp 1.9 > JupiterLib 3.5 > WordLib 3.2

Dikkat ederseniz yeni JupiterLib paketi, WordLib paketinin 3.2 versiyonunu kullanıyor. Peki bu durumda MarsLib’in durumu ne olacak? Hala WordLib 3.1 versiyonunu mu kullanıyor olacak? Cevap hayır. Go sizin adınıza MarsLib içinde 3.2 versiyonunu kullanmaya devam edecek. Buna minimal version selection deniyor. Bu ifadeyi minimum ile karıştırmamak gerekiyor. Burada amaç ortak bir versiyon seçmek ve bu sayede aynı kütüphanenin onlarca versiyonu ile uğraşmak yerine, hepsinde çalışacak bir versiyon seçmeye çalışmak. Ama tabi bu her zaman çalışmayabilir. Çünkü minimal version selection algoritması, kullanılan versiyonlar içinden en yüksek versiyonu seçecek. Dolayısıyla, MarsLib içinde breaking değişiklikler gelebilir. Bu ne kadar mantıklı, ona başka bir yazıda değinmeye çalışalım.

Bir sonra ki yazımda görüşmek üzere…