it-swarm-tr.com

Sürümdeki sayılar tipik olarak neyi temsil eder (ör. V1.9.0.1)?

Belki bu aptalca bir sorudur, ancak her zaman yazılımın tek bir bileşenini temsil eden bir süre ile tanımlanan her bir sayı olduğunu varsaydım. Eğer bu doğruysa, hiç farklı bir şey temsil ediyorlar mı? Yazılımımın farklı yapılarına sürümleri atamaya başlamak isterdim, ancak nasıl yapılandırılması gerektiğinden emin değilim. Yazılımımın beş ayrı bileşeni var.

110
BeachRunnerFred

1.9.0.1 sürümünde:

  • 1 : Büyük revizyon (yeni kullanıcı arayüzü, birçok yeni özellik, kavramsal değişim vb.)

  • 9 : Küçük revizyon (belki bir arama kutusuna yapılan bir değişiklik, 1 özellik eklendi, hata düzeltmeleri toplandı)

  • 0 : Hata düzeltme sürümü

  • 1 : Yapı numarası (kullanılıyorsa) - bu yüzden .NET Framework'ü 2.0.4.2709 gibi bir şey kullanarak görüyorsunuz

Dört düzeye inen çok fazla uygulama bulamazsınız, 3 genellikle yeterlidir.

159
Dillie-O

Semantik Sürüm özelliği var

Bu, sürüm 2.0'ın özetidir:

MAJOR.MINOR.PATCH sürüm numarası verildiğinde, aşağıdakileri artırın:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Ön sürüm ve derleme meta verileri için ek etiketler .__ olarak mevcuttur. MAJOR.MINOR.PATCH biçimindeki uzantıları.

14
magyk

Çok keyfi olabilir ve üründen ürüne farklılık gösterir. Örneğin, Ubuntu dağıtımında, 8.04, 2008 anlamına gelir.

Tipik olarak, en soldaki (büyük) sayılar, büyük bir serbest bırakmayı belirtir ve sağa ne kadar ileri giderseniz, değişiklik de o kadar küçük olur.

13
rkabir
11

Sayılar diğer cevaplar tarafından tarif edildiği gibi yararlı olabilir, ancak bunların nasıl anlamsız olabileceğini de düşünün ... Sun, Sun, Java: 1.2, 1.3, 1.4 1.5 veya 5 ve 6. 6. sürüm numaraları Meant Something. Günümüzde insanlar sürüm numaralarından vazgeçip "Feisty incir" (veya bunun gibi bir şey) ve "sert balıkçıl" ve "europa" ve "ganymede" gibi saçma isimlerle gidiyorlar. Elbette bu çok daha az kullanışlı çünkü programı değiştirmeyi bırakmadan önce jüpiter'in uyduları tükenecek ve hangisinin daha yeni olduğunu söyleyemeyeceğiniz açık bir emir olmadığı için.

8
stu

Daha fazla puan, serbest daha küçük. Bunun ötesinde gerçek bir standart yoktur - proje sahiplerinin karar verdiklerine dayanarak farklı şeyler ifade edebilir.

WordPress, örneğin, bu satırlar boyunca gider:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 - 2.0 büyük bir sürüm olur - özellikler, arayüz değişiklikleri, API'lerde büyük değişiklikler, bazı 1.6 şablonların ve eklentilerin kırılması vb. ... 2.0 - 2.0.1 küçük bir sürüm olabilir - belki de bir güvenlik hatasını düzeltebilir. 2.0.2 - 2.1 arası önemli bir sürüm olacaktır - genellikle yeni özellikler.

7
ceejayoz

Rakamlar, genellikle tek tek bileşenlerle ilgili değil, sürümünüzdeki büyük ve küçük ve bakım değişiklikleri ile ilgili olsa da, istediğiniz her şeyi ifade edebilir.

Bu kaynakları inceleyin:
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html

Şerefe

4
Alvaro Rodriguez

Sürüm numaraları genellikle ayrı bileşenleri temsil etmez. Bazı insanlar/yazılımlar için sayılar oldukça keyfidir. Diğerleri için, sürüm numarası dizesinin farklı bölümleri farklı şeyleri temsil eder. Örneğin, bazı sistemler bir dosya formatı değiştiğinde sürüm numarasının bölümlerini arttırır. Bu yüzden V 1.2.1 diğer tüm V 1.2 sürümleriyle (1.2.2, 1.2.3 vb.) Uyumlu ancak V 1.3 ile uyumlu bir dosya formatıdır. Sonuçta kullanmak istediğiniz düzeni size kalmış.

3
user9385

C # AssemblyInfo.cs dosyasından aşağıdakileri görebilirsiniz:

// Version information for an Assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [Assembly: AssemblyVersion("1.0.*")]
2
Thomas Jespersen

release.major.minor.revision benim tahminim olurdu.
Fakat ürünler arasında büyük farklılıklar gösterebilir.

2
Fire Lancer

Bu bağlıdır, ancak tipik gösterimi major.minor.release.build 'inkidir.

Nerede:

  • major, yazılımınızın ana sürüm sürümüdür, .NET 3.x'i düşünün
  • minor, yazılımınızın küçük sürüm sürümüdür, .NET x.5’i düşünün
  • release bu sürümün sürümüdür, tipik olarak bu hatalar artar.
  • build, yaptığınız yapım sayısını gösteren bir sayıdır.

Örneğin, 1.9.0.1, 1.8 ve 1.7'yi takip eden vb. Gibi yazılımınızın 1.9 sürümü anlamına gelir. 1.7, 1.8 ve 1.9 bir şekilde tipik olarak hata düzeltmelerinin yanı sıra küçük miktarlarda yeni özellikler ekler. X.x.0.x olduğundan, 1.9 sürümünün ilk sürümü ve bu sürümün ilk sürümü.

Aynı zamanda konuyla ilgili Wikipedia makalesi hakkında da iyi bilgi bulabilirsiniz.

Major.Minor.Bugs

(Ya da bunun üzerinde biraz değişiklik var)

Hatalar genellikle yeni işlevsellik içermeyen hata düzeltmeleridir.

Küçük, yeni işlevsellik katan ancak programı hiçbir şekilde değiştirmeyen bir değişikliktir.

Binbaşı, programdaki eski işlevselliği bozan bir değişiklik veya o kadar büyük ki bir şekilde kullanıcıların programı nasıl kullanması gerektiğini değiştiriyor.

2
emeryc

Herkes bu rakamlarla ne yapmak istediğini seçer. Zaten aptalca olduğundan bültenlere bültenleri çağırmak için cazip oldum. Olduğu söyleniyor, son 25 + yıllık gelişim boyunca gördüğüm şey bu şekilde çalışma eğilimindedir. Diyelim ki sürüm numaranız 1.2.3.

"1" "ana" revizyonu gösterir. Genellikle bu bir ilk sürüm, büyük bir özellik kümesi değişikliği veya kodun önemli bölümlerinin yeniden yazılmasıdır. Özellik seti belirlendikten ve en azından kısmen uygulandığında bir sonraki numaraya gidersiniz.

"2", bir seri içindeki bırakmayı belirtir. Genelde bu pozisyonu, son ana sürümde yapmayan özelliklerden haberdar olmak için kullanıyoruz. Bu pozisyon (2), genellikle hata düzeltmelerle birlikte neredeyse her zaman bir özellik eklediğini gösterir.

Pek çok mağazada "3", bir yama yayın/hata düzeltmesini gösterir. Neredeyse hiçbir zaman, en azından ticari tarafta, bu önemli bir özellik katılımı olduğunu göstermez. Eğer özellikler 3. konumda gözüküyorsa, muhtemelen bir hata düzeltme işlemi yapmak zorunda olduğumuzu bilmeden önce birisinin bir şeyi kontrol etmesinden kaynaklanıyordur.

"3" pozisyonunun ötesinde mi? İnsanların neden böyle şeyler yaptığını bilmiyorum, daha da kafa karıştırıcı oluyor.

Özellikle de OSS’nin bir kısmı, bütün bunları sıkıntıya atar. Örneğin, Trac sürüm 10 aslında 0.10.X.X'tir. ÖSS dünyasındaki birçok insanın güveninden yoksun olduğunu ya da sadece büyük bir yayın yaptıklarını duyurmak istemediklerini düşünüyorum.

1
mclain

İnsanlar, 2.1, 2.0.1 veya 2.10 gibi sürüm numaraları arasındaki ince farkı her zaman tanımıyor - teknik destek görevlisine bu konuda kaç kez sorun yaşadıklarını sorun. Geliştiriciler detay odaklı ve hiyerarşik yapılar hakkında bilgi sahibi, bu yüzden bu bizim için kör bir nokta.

Mümkünse, müşterilerinize daha basit bir sürüm numarası gösterin.

1
Mark Ransom

Büyük release.minor release.bug düzeltmesinin paradigması oldukça yaygındır, sanırım. 

Bazı kurumsal destek sözleşmelerinde, belirli bir tahliyenin nasıl belirlendiğiyle ilişkili olarak $$$ (veya sözleşme yükümlülüğünün ihlali) vardır. Örneğin, bir sözleşme bir müşteriye belli bir süre içinde belli sayıda belli başlı salınıma hak kazandırabilir veya belirli bir süre içinde x sayısından daha az sayıda salınanın olacağı ya da bu desteğin o kadar çok kişi için uygun olacağına söz verebilir. bültenleri. Elbette, önemli bir sürümün küçük sürümlere karşı ne kadar büyük olduğunu açıklamak için sözleşmeye ne kadar kelime konursa yazsın, her zaman özneldir ve daima gri alanlar olacaktır - bu da yazılım satıcısının sistemi oyuna sokma olasılığını doğurur. bu tür sözleşme hükümlerini yenmek.

1
Will M

Bir kitaplık durumunda, sürüm numarası size iki sürüm arasındaki uyumluluk düzeyini ve bu nedenle yükseltme işleminin ne kadar zor olacağını anlatır.

Bir hata düzeltme sürümü ikili, kaynak ve serileştirme uyumluluğunu korumalıdır.

Küçük sürümler farklı projeler için farklı anlamlara gelir, ancak genellikle kaynak uyumluluğunu korumak zorunda kalmazlar.

Ana sürüm numaraları, her üç formu da kırabilir.

- burada rasyonel gerekçesi hakkında daha fazla yazdım.

1
Craig P. Motlin

Binbaşı.minor.point.build genellikle. Büyük ve küçük kendi kendini açıklayıcı, nokta birkaç küçük hata düzeltmesi için bir sürüm ve oluşturma yalnızca bir yapı tanımlayıcısıdır.

1
Cody Brocious

Genellikle

MajorVersion.MinorVersion.Revision.Build

1
Jason Punyon

Evet. Büyük sürümler büyük, yeni özellikler ekler, uyumluluğu bozabilir veya önemli ölçüde farklı bağımlılıklara sahip olabilir.

Küçük sürümler ayrıca özellikler ekler, ancak beta ana sürümünden daha küçük ve bazen soyulmuş portlu sürümlerdir.

Üçüncü bir sürüm numarası bileşeni varsa, genellikle önemli hata düzeltmeleri ve güvenlik düzeltmeleri içindir. Daha fazlası varsa, genel olarak cevap vermesi zor olan ürüne o kadar bağlıdır.

1
Paweł Hajdan

İlk sayıya tipik olarak ana sürüm numarası denir. Temel olarak, yapılar arasındaki önemli değişiklikleri belirtmek için kullanılır (yani, birçok yeni özellik eklediğinizde, ana sürümü artırırsınız). Aynı üründen farklı ana sürümleri olan bileşenler muhtemelen uyumlu değildir.

Bir sonraki sayı küçük sürüm numarasıdır. Bazı yeni özellikleri veya birkaç hata düzeltmesini veya küçük mimari değişikliklerini temsil edebilir. Aynı üründen küçük sürüm numarasına göre farklılık gösteren bileşenler birlikte çalışabilir veya çalışmayabilir ve muhtemelen çalışmamalıdır.

Bir sonraki genellikle derleme numarası denir. Bu, günlük olarak veya her "serbest bırakılmış" yapıyla veya her bir yapıyla artırılabilir. Yalnızca yapı numarasına göre farklılık gösteren ve tipik olarak birlikte iyi çalışabilen iki bileşen arasında yalnızca küçük farklılıklar olabilir.

Son sayı genellikle revizyon numarasıdır. Çoğu zaman bu otomatik bir derleme işlemi tarafından veya "tek seferlik" fırlatma testleri yaparken kullanılır.

Arttırdığınızda sürüm numaralarınız size kalmış, ancak her zaman artımlı veya aynı kalmalı. Tüm bileşenlerin aynı sürüm numarasını paylaşmasını sağlayabilir veya yalnızca değiştirilen bileşenlerde sürüm numarasını artırabilirsiniz.

0
Bob King

Karmaşık bir yazılım parçasının sürüm numarası tüm paketi temsil eder ve parçaların sürüm numaralarından bağımsızdır. Gizmo 3.2.5 sürümü, Foo 1.2.0 sürümünü ve Bar 9.5.4 sürümünü içerebilir.

Sürüm numaraları oluştururken bunları aşağıdaki şekilde kullanın:

  1. İlk sayı ana sürümdür. Kullanıcı arayüzünde önemli değişiklikler yaparsanız veya mevcut arayüzleri kırmanız gerekirse (kullanıcılarınızın arayüz kodlarını değiştirmeleri gerekir), yeni ana sürüme geçmelisiniz. 

  2. İkinci sayı, yeni özelliklerin eklendiğini veya bir şeyin dahili olarak farklı şekilde çalıştığını göstermelidir. (Örneğin, Oracle veritabanı veri almak için farklı bir strateji kullanmaya karar verebilir, çoğu şeyi daha hızlı hale getirir ve bazı şeyleri yavaşlatır.) Mevcut arayüzler çalışmaya devam etmeli ve kullanıcı arayüzü tanınabilir olmalıdır. 

  3. Sürüm numaralandırması ayrıca yazılımı yazan kişiye bağlıdır - Oracle beş (!) Grup kullanır, yani. Oracle sürümü 10.1.3.0.5 gibi bir şey. Üçüncü gruptan itibaren işlevsellikte yalnızca hata düzeltmeleri veya küçük değişiklikler yapmalısınız. 

0
Sten Vesterli
0
Sijin

daha az değişken olanlar, major.minor için ilk ikisi olacaktır; bundan sonra, derleme, revizyon, sürümden herhangi bir özel algoritmaya (bazı MS ürünlerinde olduğu gibi) kadar olan herhangi bir şey olabilir

0
BlackTigerX

İşte ne kullanıyoruz:

  1. İlk sayı = Genel sistem dönemi. Her iki yılda bir yapılan değişiklikler ve genellikle teknolojide veya müşteri özelliklerinde veya her ikisinde temel bir değişiklik anlamına gelir.
  2. İkinci sayı = veritabanı şeması revizyonu. Bu sayıdaki artış, veritabanı geçişi gerektirir ve bu da önemli bir değişikliktir (veya sistemler çoğalır ve bu nedenle veritabanı yapısını değiştirmek dikkatli bir yükseltme işlemi gerektirir). İlk sayı değişirse 0 olarak sıfırlanır.
  3. Üçüncü sayı = sadece yazılım değişir. Bu, genellikle veritabanı şeması değişmediği için müşteri bazında uygulanabilir. İkinci sayı değişirse sıfırlanır.
  4. Subversion sürüm numarası. TortoiseSVN aracını kullanarak bunu otomatik olarak oluştururken dolduruyoruz. Bu sayı asla sıfırlanmaz, ancak sürekli artışlar. Bunu kullanarak herhangi bir sürümü her zaman yeniden oluşturabiliriz.

Bu sistem bize iyi hizmet veriyor çünkü her sayının açık ve önemli bir işlevi var. Büyük sayı/küçük sayı sorusu ile boğuşan başka takımlar gördüm (bir değişimin ne kadar büyük olduğu) ve bunun faydasını göremiyorum. Veri tabanı revizyonlarını izlemeniz gerekmiyorsa, sadece 3 veya 2 basamaklı bir sürüm numarasına gidin ve hayatı kolaylaştırın!

0
Ewan Makepeace

V1.9.0.1 sürümünde: Bu, açık sürüm oluşturma şemasıdır, ön sürümlerde adı kullanmak istemediğinizde veya -alpha, -beta gibi bir yapı oluşturmak istemediğinizde kullanılır.

1: Geriye dönük uyumluluğu bozabilecek ana sürüm

9: Uygulamanızı desteklemek için yeni özelliklerin eklenmesiyle önceki sürümle geriye dönük uyumluluk.

0: Bazı küçük hata düzeltmeleri

1: Yapı numarası (Sürüm öncesi numarası)

ama günümüzde, böyle bir versiyonlandırma şeması bulamazsınız. Anlamsal Sürümleme [semver2.0] https://semver.org/

0
Mehul Sancheti

Her organizasyon/grubun kendi standardı vardır. Önemli olan, seçtiğiniz notasyona bağlı kalmanız, aksi takdirde müşterilerinizin kafasının karışmasıdır. Normalde 3 sayı kullandığımı söyledim:

x.yz.bbbbb. Nerede: X: ana sürüm (ana yeni özellikler) Y: küçük sürüm numarası (küçük yeni özellikler, kullanıcı arayüzü değişikliği olmadan küçük iyileştirmeler) Y: hizmet paketi (temel olarak aynı xy olarak ancak bazı hata düzeltmeleri ile. bbbb: yapı numarasıdır ve müşteri desteği için diğer detaylarla birlikte yalnızca "hakkında" kutusundan görülebilir. bbbb ücretsizdir ve her ürün kendi kullanabilir.

0
Vasco Duarte

Büyük, küçük, yama, yapı, güvenlik düzeltme eki vb.

İlk ikisi büyük ve küçük - geri kalanı projeye, şirkete ve bazen topluluğa bağlı olacak. İşletim sistemindeki FreeBSD benzeri bir güvenlik yamasını temsil etmek için 1.9.0.1_numara sahip olacaksınız.

0
Loren Segal

Dile bağlı olarak, Delphi ve C # gibi farklı anlamlara sahipler.

Genellikle, ilk iki sayı büyük ve küçük bir versiyona karşılık gelir, yani ilk gerçek sürüm için 1.0, bazı önemli hatalar ve küçük yeni özellikler için 1.1, büyük yeni bir özellik sürümü için 2.0.

Üçüncü sayı "çok küçük" bir versiyona veya revizyona atıfta bulunabilir. 1.0.1 örneğin 1.0.0 için çok küçük bir hatadır. Ancak, Revizyon numarasını Kaynak Kontrol Sisteminizden de taşıyabilir veya her yapıyla birlikte artan, sürekli artan bir sayı taşıyabilir. Veya bir Tarih Damgası.

Biraz daha fazla ayrıntı here . Net'te "resmen", 4 sayı "Major.Minor.Build.Revision", Delphi'de "Major.Minor.Release.Build" yazıyor. Sürümüm için "Major.Minor.ReallyMinor.SubversionRev" kullanıyorum.

0
Michael Stum

Genelde o zaman sayı bireysel iç bileşenler değil, version.major.minor.hotfix biçimindedir. Dolayısıyla v1.9.0.1 sürüm 1, büyük sürüm 9 (v1'den), küçük sürüm (v1.9) 0, sıcak düzeltme 1 (v1.9.0) olacaktır.

0
Scott Bevington