Bağımlı yazılım bileşenlerinin sürüm numaralandırması için en iyi uygulamayı arama

Birbirine bağlı olan yazılım bileşenleri için sürüm numaralandırması yapmanın iyi bir yoluna karar vermeye çalışıyoruz.

Daha spesifik olalım:

Yazılım bileşeni A, yerleşik bir aygıtta çalışan bir bellenimdir ve bileşen B, normal bir PC (Linux / Windows makinesi) için ilgili sürücüsüdür. Özel bir protokol kullanarak birbirleriyle iletişim kuruyorlar. Ürünümüz aynı zamanda geliştiricileri de hedef aldığından, her iki bileşenin de kararlı ve dengesiz (deneysel) sürümlerini sunacağız (ürün yazılımı açık kaynak iken, ürün yazılımı kapalı kaynaktır). En büyük zorluğumuz iletişim protokolündeki API değişikliklerinin nasıl ele alınacağıdır.

Sürücüde bir uyumluluk denetimi uygularken - bellenim sürümünün sürücü sürümüyle uyumlu olup olmadığını kontrol eder - sürüm numaralandırmanın birden çok yolunu tartışmaya başladık.

Tek bir çözüm bulduk, ama tekerleği yeniden icat etmek gibi hissettik. Bu yüzden programcı / yazılım geliştirici topluluğundan bazı geri bildirimler almak istiyorum, çünkü bunun ortak bir sorun olduğunu düşünüyoruz.

İşte çözümümüz:

Yaygın olarak kullanılan major.minor.patch sürüm numaralandırmasını izlemeyi ve kararlı / kararsız sürümler için çift / tek küçük sayıları kullanmayı planlıyoruz . API'da değişiklikler yaparsak küçük sayıyı artıracağız.

Bu sözleşme aşağıdaki örnek duruma yol açacaktır:

Mevcut kararlı dal 1.2.1 ve kararsız 1.3.7'dir. Şimdi, kararsız için yeni bir yama API'yi değiştirir, bu da yeni kararsız sürüm numarasının 1.5.0 olmasına neden olur. Bir kez, kararsız dal stabil olarak kabul edilir, diyelim ki 1.5.3'te 1.4.0 olarak serbest bırakacağız.

Aşağıdaki ilgili soruların cevaplarından memnun olurum:

• Yukarıda açıklanan sorunları ele almak için en iyi uygulamayı önerebilir misiniz?
• "Özel" sözleşmemizin iyi olduğunu düşünüyor musunuz?
• Açıklanan sözleşmede hangi değişiklikleri uygularsınız?

IMHO sürüm numaraları ürün adları gibidir; görünür olmaları, içerikten ziyade dekorasyon olmaları bakımından önemsiz olmaları önemlidir.

Yine de ürün numarası gibi sürüm numarası anlam taşır. Ve yapabileceğiniz en önemli şey karışıklıktan kaçınmaktır. İşte sürüm numaraları ile ilgili bazı ortak beklentiler . Bu istisnaların karşılanmadığı ölçüde, kullanıcı muhtemelen karışacaktır:

Sürüm numaraları monoton olarak artıyor
Bu muhtemelen en bariz beklenti ve aynı zamanda gerçekte en az doğru olma ihtimalidir. Bir bakışta, kullanıcı 2.3.5 sürümünün 2.2.17 sürümünden sonra gelmesini ve aynı veya daha iyi teknolojiye sahip olmasını bekler . Ancak elbette 2.3.x bir geliştirme dalıdır ve 2.2.x stabildir ve 2.3.5 aslında 2004'te piyasaya sürülmüştür ve 2.2 şube hala aktif olarak çalışmaktadır ve 2.2.17 geçen Nisan ayında piyasaya sürülmüştür ve içerir. .. peki, fikri anladınız. Sadece sayı taşıdığı tüm anlam için sürüm 2.2 "Patates" diyebilirsiniz. Sürüm " Patates-17 " hoş geldiniz !!

Benzer Sürümler Yükseltilebilir / Uyumlu
Bilgisayarımda sürüm 3.7 varsa ve 3.8 tüm yeni parlak frozbot'larla çıkarsa, bazı yükseltme veya yamalarla ya da her neyse, 3.7'imin kesintisiz olarak 3.8 olabileceğini umuyorum. Ama eğer 3.7'deysem ve 5.2'yi bırakırsanız, o kadar iyimser değilim. Tabii ki, hayal kırıklığına uğramak yerine hoş bir sürpriz olmayı tercih ederim.

İlk rakam önemlidir,
eğer Java bu konuda çok kafa karıştırıcı olmasaydı bundan bahsetmek bile istemezdim. Birisi size söylemediği sürece, "Java 7" nin aslında 1.7 sürümü olmasını beklemezsiniz. Ve bunu ilk kez duyduğunuzda, yanıtınız neredeyse kesinlikle şuydu: " Ne? .. Neden? "

Açıkça anlaşılır ki, ana sürüm numarası sadece platform değişikliği geriye dönük uyumlu değilse değişecektir. Ama aslında hiç uyumluluğu geriye düşürmeyi düşünüyor musunuz? Genellikle büyük sürüm devirleri teknik bir karar değil pazarlama kararıdır; Java saçmalık, her iki kamptan da aynı anda kendi yollarına sahip, neredeyse komik bir etki yaratıyor.

Son
olarak daha önce de belirttiğim gibi, sürüm numaraları pazarlama ile ilgili olduğu kadar teknoloji ile de ilgilidir. Ve bu tamam, çünkü bu sürüm numaraları için bir şey: yazılım hakkında yeni olan şeyleri bir bakışta bilgilendirin. Büyük sayı değişikliği, büyük işlevsellik değişikliği anlamına gelir. Küçük sayı değişikliği neredeyse hiçbir işlevsellik değişikliği anlamına gelmez. İnsanlar bunu bekler . Doğru olup olmadığı, sürüm numaralarınızın kullanıcılarınızın düşündükleri aynı anlama sahip olup olmadığını belirler.

- EDIT - Bundan
bahsetmeyi unuttum, ama Caleb güzel bir şekilde işaret etti: Başka bir yerde açıkça belirtmeden önemli bir şeyi (örneğin, kararlı / kararsız) belirtmek için sürüm numaralarını kullanmayın. Evet, sen tek alt sürüm numarası gelişimini gösterir biliyoruz, ama bu bizden biri yapar. Debian'ın "kararsız" serbest bırakma lakabı buna iyi bir örnektir; veya tamamen ayrı bir ürün adı da kullanabilirsiniz; Ürün adınız için "Frozbot 1.2" ve geliştirme sürümünüz için "Devbot 1.3".

Bir kez, kararsız dal stabil olarak kabul edilir, diyelim ki 1.5.3'te 1.4.0 olarak serbest bırakacağız.

Hayır hayır. Kararsız 1.5.3 için kararlı 1.6.0'dan başlamalıdır (ve Semantik Sürümleme kullanmak istemiyorsanız 1.4.x kaçırdı)

İki ayrı şeyi belirtmek için bir değer kullanmaya çalışıyorsunuz.

İlk olarak, genellikle çeşitli sürümleri belirlemeye ve sürümlerin hangi sırayla yapıldığını göstermeye yarayan bir "sürümünüz" vardır. Tyler'ın dediği gibi, sürüm her zaman artmalıdır - sürümü 1.5.3'ten 1.4.0'a değiştirirseniz, kullanıcılar için herhangi bir anlam ifade etmez (ve çok fazla iç karışıklığa neden olabilir).

İkincisi, belirli bir sürümün kararlı olup olmadığını belirtmeye çalışıyorsunuz.

Bu var mümkün bazı mağazalar bir öğe satışa olup olmadığını göstermek için bazı fiyatlandırma şemasını kullanır gibi "sürüm numarası" tek hem şeyleri belirtmek için. Örneğin, yakınımdaki bir mağazada '3' ile biten fiyatlar nihai satış fiyatlarıdır. Bu, bir satış fiyatını nasıl belirleyeceğini hızlı bir şekilde öğrenen çalışanlar için iyi çalışır, ancak müşterilerinize bir satış hakkında bilgi vermenin harika bir yolu değildir. Bu nedenle, satış kalemlerinin yanına da tabela koydular. Hatta kararlı sürümler için en az rakamı yapmak ve deneysel sürümler için tuhaf hale getirmek gibi benzer bir şey yapabilirsiniz. Bununla birlikte, deneysel bir şeyi serbest bırakacaksanız, bunu bu şekilde açıkça işaretlemeniz gerektiğini düşünüyorum. Sürüm dizesinin başına veya sonuna 'X' ekleyebilirsiniz, örneğin:X.1.5.31.5.3.X. Bundan sonra deneysel bir sürüm numarası bile alabilirsiniz, böylece hepsi aynı temel sürüme dayanan birden fazla deneysel sürüm yayınlayabilirsiniz: 1.5.3.X1, 1.5.3.X2.

Ayrıca "alfa" ve "beta" sürüm numaralarını kullanarak uzun bir geleneği var olduğunu göz önünde bulundurmalıdır stabil veya tam olmayabilir versiyonlarını belirtmek için: 1.5.3a54. Başka bir şey yapmaya karar verirseniz, bu şemadan ayrılmak için iyi bir nedeniniz olduğundan emin olun, çünkü muhtemelen geliştirici topluluğunuza başka bir şey açıklamak zorunda kalacaksınız.

Istikrarlı / kararsız sürümleri için bir uzantı "etiketi" kullanarak major.minor.patch biçimini ve büyük ve küçük sayıların kesin bir anlamını kullanmanızı öneririm:

major.minor.patch-stable|unstable

nerede

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

Bu şekilde bağımlılıklar kolayca yönetilir ve her bileşen istemcisine / kullanıcıya yeni sürümlere daha fazla dikkat etmeleri gerektiğini söyler. Örneğin, A bileşeni (1.1.0-kararlı) B'ye (5.4.534-kararlı) bağlıysa ve B'nin yeni bir sürümünün (6.1.0-kararsız) olması gerekiyorsa, A'nın büyük olasılıkla büyük ölçüde değiştirilmesi gerektiğinin hemen farkındadır. .

Hibernating Rhinos'un RavenDb-vis-a-vis versiyonlarını oluşturma şeklini gerçekten çok seviyorum - sadece artan bir yapı numarasına sahipler. İstikrarlı olduklarında kararlı olarak işaretlenirler. Ama her şey bir sürüm adayı.