Hangi "sürüm adlandırma kuralı" kullanıyorsunuz?

Anlamsal Sürüm Oluşturma ( http://semver.org/ ) burada bir sözü hak ediyor. Bir sürüm oluşturma şemasının [Major].[Minor].[Patch]. Bu şemanın motivasyonu anlamı sürüm numarasıyla iletmektir.

Kullanmıyorum ama gördüm ve ilginç bir yapı:

Year.Month.Day.Build

Kendini açıkladı.

RubyGems Rational Versioning ilkesi hangi kullanmaya çalışın:

• Büyük sürüm numarası ikili uyumluluk bozulduğunda artar
• Yeni işlev eklendiğinde alt sürüm numarası artırılır
• Hata düzeltmeleri için yapı numarası değişir.

Sürüm numaralandırmaya yönelik çok hassas bir yaklaşım:

• N.x.K; burada N ve K tamsayıdır. Örnekler: 1.x.0, 5.x.1, 10.x.33. ara yapılar için kullanılır.
• N.M.K; burada N, M ve K tamsayıdır. Örnekler: 1.0.0, 5.3.1, 10.22.33. sürümler için kullanılır.
• N.x.x; burada N tamsayıdır. Örnek: 1.x.x. Destek şubeleri için kullanılır.
• N.M.x; burada N ve M tamsayıdır. Örnek: 1.0.x. serbest bırakma dalları için kullanılır.

Sürüm numaralandırma yaklaşımının basit bir resmi için resim:

PA, alfa öncesi A anlamına gelir alfa B anlamına gelir beta AR alfa serbest bırakma BR beta- sürüm RC sürüm adayı ST kararlı anlamına gelir

Bu sürüm numaralandırma yaklaşımının avantajları şunlardır:

• çevik yazılım geliştirme yaşam döngüsünün özelliklerini temsil eder.
• kaynak kodu depo yapısının özelliklerini dikkate alır.
• Bu kalıplara alışmış olanlar için kendini açıklamak. Her desen farklı yapıları temsil eder. Bu tür kalıplar kolayca ayrıştırılabilir ve sorun izleme gibi diğer amaçlar için kullanılabilir.
• Açıklanan sürüm oluşturma yaklaşımı için temel olan ölçüm metrikleri ve planlama için sürüm kalıpları seti.
• vade ve kalite düzeyi kavramlarına odaklanmıştır. Çok sık olarak 1.0.0 gibi sürüm numaraları çok fazla gerek olmadan atanır (yazılım derin alfadayken). Sunulan sürüm numaralandırma yaklaşımı, birkaç olgunluk düzeyi oluşturulmasına olanak tanır. En basit durumda sadece iki seviye olacaktır: orta seviye yapı (N.x.K) ve sürüm (N.M.K). Sürüm, tam sürüm numarasına sahip yazılım parçasının (N.M.K) tedarikçi şirket/kuruluş/ekip içinde bir tür kalite yönetimi sürecinden geçtiğini ifade eder.
• Bu hem geliştirme hem de testin çevik doğası bir kanıtıdır.
• Yazılım yapısını ve mimarisini modüler yaklaşım teşvik eder.

Daha karmaşık diyagram modelleme yaklaşımını detaylı olarak temsil etmektedir. Ayrıca sürümleme yaklaşımına geçişi açıklayan sunum slaytları ve sürüm numaralandırma yaklaşımının temel prensiplerini gösteren SCMFViz uygulamasını bulabilirsiniz. Sunum slaytları, yazılım projesinin tüm ömrü boyunca aynı sürüm oluşturma yaklaşımına bağlı kalmanın neden önemli olduğunu da açıklar.

Şahsen benim gerçek sürüm numaraları yerine tarih sürümü benim tutum benim tarihli sürümleri ile yazılım geliştiricileri varsayar:

• Yazılım geliştirme yaşam döngüsü hakkında hiçbir şey bilmiyor. Geliştirme genellikle çevik ve yinelemelidir. Sürüm numaralandırma yaklaşımı, yazılım geliştirme sürecinin yinelemeli niteliğini temsil etmelidir.
• Yazılım kalitesine önem vermeyin . Kalite kontrol ve güvence çevik ve yinelemelidir. Tıpkı gelişme gibi. Ve sürüm numarası, hem geliştirme hem de kalite kontrol/güvencenin çevik ve yinelemeli niteliğinin kanıtı olmalıdır.
• Uygulamalarının mimari veya fikri ile ilgilenmeyin. N.M.K içindeki ana sürüm numarası (N hem mimari çözümden hem de temelden sorumludur uygulama ilkesi. Ana sürüm numarası N mimarideki değişikliklere veya ana fikir ve çalışmalarının/çalışma prensiplerindeki değişikliklere göre değiştirilmelidir.
• Kod tabanları üzerinde kontrol sahibi değilsiniz. Muhtemelen sadece bir dal (gövde) vardır ve her şey için kullanılır. Ben şahsen kodbase bir büyük çöp dökümü olmak için teşvik olarak doğru olduğunu düşünmüyorum.

Bu yaklaşım biraz tartışmalı görünebilir, ancak bunun yazılıma uygun sürüm numaraları vermenin en basit yolu olduğuna inanıyorum.

Yayınladığınız her büyük sürüm için, dahili olarak adlandırdığınız çalışan bir sürüme sahip olmak nadir değildir. Örneğin, son işimde, Ubuntu'dan ilham alan aşağıdaki adlandırma kuralına sahip büyük bir sürüme değindik:

[hastalıklı durum] [alliteratif hayvan adı]

" Limp Lamprey ", " Yaralı Wombat " ve " Astımlı Karıncayiyen ".

Gerçekten harika bir isim olmadığı sürece, müşterilerinize sızmadığından emin olun.

Nesil Versiyon Revizyon Binası (9.99.999.9999)

Nesil nadiren değişir. Ürünü sadece büyük bir dönüş yapın: DOS -> Windows, tam yeniden yapılandırma.

Sürüm, büyük uyumsuz değişiklikler, yeni işlevler, yazılımdaki bazı belirli paradigmalarda değişiklikler vb. İçindir.

Revizyon genellikle yapılır (küçük özellikler ve hata düzeltmesi).

Yapı dahili bilgidir.

git describe seçtiğiniz numaralandırma kuralına güzel bir eklenti sağlar. Bunu derleme/paketleme/dağıtım işleminize dahil etmek yeterince kolaydır.

Etiketli sürüm A.B.C (major.minor.maintenance) adını verdiğinizi varsayalım. git describe verilen bir taahhütte, taahhüdün en son etiketli atalarını bulur, ardından o zamandan beri taahhütlerin sayısını ve taahhütün kısaltılmış SHA1'ini ele alır:

1.2.3-164-g6f10c

Aslında sürümlerden birindeyseniz, elbette etiketi alırsınız (1.2.3).

Bu, her bir kaynağın kendiniz numaralandırılmasına gerek kalmadan, hangi kaynaktan geldiğinizi ( tam olarak bilmenizi sağlamanın güzel bir yararı vardır.

Bazı anlamsal anlamlar veren sürüm numaralarını tercih ederim. Kaynak kodunda (ve etkinlik yönetim sisteminizde) meydana gelen değişikliklerde belirli bir sürümle bildirilen hataları izlemek için sürüm numarasını kullanabildiğiniz sürece, muhtemelen doğru yöntemi kullanıyorsunuzdur.

.NET kullanıyorum, bu yüzden .NET sürüm numaralandırma sistemine takılı kaldım ama sayılara anlamsal anlam vermeye çalışıyorum

ana.Alt.Yapı.Düzeltme

• major = (projeye kadar)
• minor = (projeye kadar)
• build = Hudson'dan derleme numarası (burada TeamCity veya TeamBuild vb. kullanabilirsiniz)
• revizyon = Subversion veya Bazaar revizyonu (projeye ve ne kullandığına bağlı olarak)

Her zaman sürüm numarasının bir şekilde görünür olduğundan emin oluruz (toplu konsol tabanlı programlarımız konsola yazdırılır ve bir günlük dosyası ile, web uygulamaları genellikle üstteki menü çubuğundadır)

Bu şekilde, istemciler sorun bildirirse, en son sürümü kullanıp kullanmadığını ve belirli sürümlerde ne kadar sorun yaşadığımızı izlemek için sürüm numarasını kullanabiliriz.

Her şey izlenebilirlikle ilgili!

Major.Minor.Public (derleme) [alfa/beta/deneme], örneğin "4.08c (1290)"

• Büyük sürümün ana sürüm numarası olması (1, 2, 3 ...)
• Minör 2 basamaklı minör bir versiyondur (01, 02, 03 ...). Tipik olarak onlarca basamak önemli yeni işlevler eklendiğinde artar, sadece hata düzeltmeleri için olanlar.
• Genel, küçük bir sürüm hiçbir zaman genel güncelleme olarak yayınlanmazsa, genellikle küçük sürümden farklı olan yapının (a, b, c, d, e) genel sürümüdür.
• derleyicinin izlediği gerçek derleme numarası olmak.
• bu özel durumlar için TRIAL, ALPHA, BETA X veya RC X eklenmiştir.

Major.Minor.Build # .YYMMDD [sonek] kullanırız, çünkü genellikle belirli bir günde sadece bir üretim inşa ederiz (ancak birden fazla varsa ab/c/d son eki kullanırız) ve YYMMDD, kullanıcılara/müşterilere/yönetime 6.3.1389'un yapmadığı yaşın bir göstergesini verir.

Önemli ürün özellikleri (ücretli) ile ana sayılar artar.

Düzeltmeler/iyileştirmelerle küçük sayılar artar (ücretsiz güncelleme).

Yapı her zaman artar; hepsi gemi inşa etmez, bu yüzden doğrusal bir ilerleme değildir.

 1.0.0 
 | 
 1.0.1 
 | 
 (Genel 1.0) 1.0.2 ----- 
 |\
 2.0.0 1.1.0 
 | | 
 2.0.1 1.1.1 (genel 1.1) 
 | 
 (Genel 2.0) 2.0.2 ----- 
 |\
 3.0.0 2.1.0 
 | 
 2.1.1 (genel 2.1) 
 | 
 2.2.0 
 | 
 2.2.1 

X.Y.Z Dahili sürüm numaramızdır. X.Y, Müşterilerimiz için bir anlam ifade eden genel sürüm numarasıdır. Bir X.Y.Z Sürümü herkese açık hale geldiğinde, asla X.Y.(Z+1) sürümü olmayacaktır: genel sürüm her zaman dizinin sonuncusudur.

X ana sürüm yayınlandığında artırılır.

Y bu büyük sürümlerin bakım dalları için, sadece hata düzeltmeleri için kullanılır.

Z dahili olarak kullanılır ve sabit bir anlamı yoktur. Şimdiye kadar, uygulamanın geliştiricilere göstermek için ilginç bir dizi özelliğe sahip olduğunu ve nispeten kararlı olduğunu düşündüğümde yeni bir Z sürümü oluşturuyorum. Bu şekilde, birisi sorulduğunda uygulamanın "son bilinen iyi sürümü" bir demo gösterebilir. Yakın bir gelecekte, hata takipçimizde özelliklerin "hedefini" adlandırmak için Z sayı sürümlerini kullanmayı planlıyorum.

Yan not olarak, sürüm numarasını artırmak için maven (release komutuyla) kullanırız. Dolayısıyla, X.Y.Z-SNAPSHOT Sürümü de vardır (X.Y.(Z-1) ve X.Y.Z Arasındaki herhangi bir sürümü gösterir).