Proje Yayın Durumları (Release Status)
Bir uygulama geliştirildiğinde veya kullanmak amacıyla edinilmek istendiğinde uygulama sayfalarında projenin durumuna ve geliştiriciye dair çeşitli durum ibarelerinin yer aldığını görürüz.
Çoğu durumda bu ibareler projenin kim tarafından, ne zamandan beri ve hangi lisans altında (released under the MIT License gibi) geliştirildiği bilgisini bize verirler; developed by x, maintained by y vb. Özellikle açık kaynaklı projelerde bir projenin kim (kişi, kurum vb.) tarafından, ne zamandan beri geliştirildiği, ilk yayının (release) ne zaman yapıldığı, güncel sürüm bilgisi, ne sıklıkla güncellemelerin (update) yayınlandığı gibi bilgiler o projenin de ciddiyetini göstermektedir.
Ayrıca, GitHub gibi sürüm kontrol sistemlerinden de aşina olduğumuz üzere, kimi durumda da projelerin dalları (branches), çatal olarak ifade edebileceğimiz alternatif geliştirmeleri (fork) ve hatta torun (descendant) olarak nitelendirebileceğimiz daha kapsamlı alternatifleri ortaya çıkabilir. Bu tür durumlarda da çoğu zaman ilgili proje sayfasında (çoğu durumda README dosyasında projeyi kim(ler)in koruduğu ve katkıda bulunduğu) durum sürüm ve bakım (release and maintenance) başlığı altında ayrıca belirtilir. Örnek olarak bir WordPress çoklu dil eklentisi olan qTranslate ele alınabilir1. Bu eklenti çok uzun zaman önce bir geliştirici desteği (maintainer, contributor vb.) olmadığı için sonlandırılmıştır. Bu sonlandırılma durumu eğer proje bir versiyon kontrol sisteminde barındırılmakta ve dal veya çatallandırılmışsa (deprecated) ibaresi ile belirtilmektedir. Bu sayede yeni alternatiflerin tercih edilmesi sağlanır.
Ek olarak, uygulamanın geliştiricisi uygulamadan desteğini çekmiş ise bu durumu not maintained olarak ifade (annotation) eder. Tekrar örneğe dönecek olursak, qTranslate eklentisinin desteklenmiyor (desupported) oluşu sebebiyle ihtiyaçlar doğrultusunda yeni bir alternatif ortaya çıkmıştır; qTranslate X. Bu eklenti, qtranslate’in güncel ihtiyaçlara uygun ve daha özellikli türevi olarak ifade edilebilir. Eklenti sayfasında şu ifadeye yer verilmektedir; “QTranslate-X eklentisi, Qian Qin tarafından geliştirilen qTranslate’in soyundan gelmektedir.“. Ancak, QTranslate-X eklentisi de uzun bir süre boyunca güncellenmeyip ve hatalardan arındırılmayınca2 bir başka geliştirici veya geliştirici grubu projenin devamlılığını üstlenebilir. Yine qTranslate eklentisine dönecek olursak; zTranslate, qTranslate Plus, mqTranslate ve qTranslate XT gibi fork’lar örnek olarak gösterilebilir. Elbette bu fork‘ların çoğu da zaman içerisinde geliştirici desteğini kaybetmiştir. qTranslate XT ile ilgili daha önce bir yazım olmuştu, bu yazıda genel olarak geliştirilme sürecine değinmiştim. İlgili yazıda bahsi geçmemiş olan bir not ekleyeyim. qTranslate XT3, qTranslate’in de geliştiricisinin de aralarında bulunduğu bir geliştirici grubu tarafından desteklenmektedir. Elbette bu süreç örnek olarak gösterilebilecek onlarcasından sadece biri. Bu sürece ekti eden daha pek çok durum olabilir. Git SCM ve/veya MariaDB yazılarında da kısmen bahsi geçtiği üzere farklılaşmanın ya da yeni bir oluşumun kurumsal bir nedeni de olabilir.
Yine, R programlama dili aracılığıyla WordPress XML-RPC erişiminde kullandığım paket de yayınlanan R sürümlerinin gerisinde bir güncellemeye sahip olduğu için kapsam dışında kaldı. Bu gibi durumlarda fork için var olan uygulamanın sağladığı avantajlar göz önünde bulundurulabilir. XML-RPC zaman içerisinde yerini REST API‘e bıraktığı için ilgili paketin güncellenmesi çok bir fayda sağlamayabilir. Dolayısıyla, geliştirici ilgili geliştirme için bir status belirtmemiş olsa dahi biz ilgili bağımlılıkları deprecated olarak nitelendirip daha kapsamlı ve uzun vadeli çözümlere odaklanmalıyız.
Özetle, bir proje de tıpkı bir organizma gibi yaşam döngüsüne sahiptir. Bir ihtiyaç doğrultusunda ortaya çıkan bir proje bu yaşam döngüsü içerisinde gelişir, çoğalır, kimi parçaları güncel gereksinimlere uyum sağlayamadığı için körelir veya tersi bir durumda daha gelişir ve bir başka uygulama için kaynak görevi görür. Bu nedenle, bir proje geliştirirken veya bir bir bağımlılık (module, component, library, framework vb.) proje içeriğine dahil edilirken geliştirici desteği de ayrıca değerlendirilmelidir. Özellikle yayın durumları release status ayrıca gözden geçirilmelidir. Not maintained (no longer actively maintained) ve/veya deprecated bir uygulamanın çoğu zaman alternatifleri de işaret edilir. Bu tür durumlarda alternatiflere yönelmek daha doğru bir karar olacaktır. Elbette bu durumda sürüm farklılıkları ve özellikler bağlamında yeni bazı düzenlemeler de gerekebilir. Aşağıda, İleri Okumalar başlığı altında incelemenizi önereceğim bazı örnekler ve ilgili tartışmaların bağlantıları yer almakta.