En İyi Uygulama: Yazılım Sürümü [kapalı]

Boş zamanlarınızda geliştirdiğiniz bir yazılımı eğlenmek için nasıl güncelleyeceğinize dair bir kılavuz veya standart en iyi uygulama var, ancak yine de bazı insanlar tarafından kullanılacak mı? Ben böyle bir yazılım sürümü gerekli olduğunu bilerek sürüm hakkında bilmek bence gerekli (örneğin hata düzeltme, destek, vb için).

Ancak sürümlemeye nereden başlayabilirim? 0.0.0? veya 0.0? Ve sonra sayıları nasıl arttırabilirim? büyük sürüm. küçük değişiklik? ve herhangi bir sürüm kontrol sistemine bağlılık başka bir sürüm olmamalı mı? yoksa bu yalnızca verimli bir şekilde kullanılan sürümler için mi?

"Serbest bıraktığınız" ilk sürümün bir şekilde eksik olduğunu bilmiyorsanız, sürüm 1 ile başlamalısınız.

Sürümleri nasıl artırdığınıza gelince, bu size bağlıdır, ancak ana, küçük, yapı numaralandırmasını kılavuz olarak kullanın.

Kaynak kontrolüne taahhüt ettiğiniz her sürümün başka bir sürüm olarak olması gerekli değildir - yakında çok büyük bir sürüm numarasına sahip olacaksınız. Sürüm numarasını yalnızca bir şekilde dış dünyaya yeni bir sürüm yayınladığınızda artırmanız gerekir.

Yani 1.0.0.0 sürümünden 2.0.0.0 sürümüne büyük bir değişiklik yaparsanız (örneğin WinForms'dan WPF'ye geçtiniz). Daha küçük bir değişiklik yaparsanız 1.0.0.0'dan 1.1.0.0'a geçin (png dosyaları için destek eklediniz). Küçük bir değişiklik yaparsanız, 1.0.0.0'dan 1.0.1.0'a gidin (bazı hataları düzelttiniz).

Gerçekten ayrıntılı almak istiyorsanız, her iade / taahhüt için artan yapı numarası olarak son numarayı kullanın (ama bence bu çok ileri gidiyor).

Bir x.y.zçeşit versiyonlama kullanırdım

x- büyük sürüm
y- küçük sürüm
z- sürüm numarası

Temel olarak bu kalıbı takip ediyorum:

• 0.1.0'dan başlar

• hazır olduğunda kodu kaynak deposuna koyarım, 0.1.0 etiketini ekler ve 0.1.0 dalını yaratırım, baş / gövde 0.2.0-anlık görüntü veya benzeri bir şey olur

• Sadece gövdeye yeni özellikler ekliyorum, ancak backport şubeye gider ve zamanla 0.1.1, 0.1.2, ...

• Ürünün özellik tamamlandığı ve önemli eksiklikleri olmadığı zaman 1.0.0 sürümünü beyan ederim

• o andan itibaren - herkes ana sürümü ne zaman artıracağına karar verebilir ...

Bu kuralı uygulamalarım için kullanıyorum:

xyz

Nerede:

• x = ana sürüm numarası, 1- ~.
• y = özellik numarası, 0-9. Değişiklik hata düzeltmeleri olsun veya olmasın yeni özellikler içeriyorsa bu sayıyı artırın.
• z = düzeltme numarası, 0- ~. Değişiklik yalnızca hata düzeltmeleri içeriyorsa bu sayıyı artırın.

Misal:

• Yeni uygulama için sürüm numarası 1.0.0 ile başlar.
• Yeni sürüm yalnızca hata düzeltmeleri içeriyorsa, sürüm numarasını 1.0.1 olacak şekilde düzeltme numarasını artırın.
• Yeni sürüm, hata düzeltmeleri olan veya olmayan yeni özellikler içeriyorsa, özellik numarasını artırın ve sürüm numarasını 1.1.0 olacak şekilde düzeltme numarasını sıfırlayın. Özellik numarası 9'a ulaşırsa, ana sürüm numarasını artırın ve özellik ile düzeltme numarasını sıfırlayın (2.0.0 vb.)

Burada abcd kullanıyoruz

• a - ana (müşteriye teslim edildiğinde artırılır)
• b - küçük (müşteriye teslim edildiğinde artırılır)
• c - revizyon (dahili sürümlerde artar)
• d - yapı (hız sabitleyici tarafından artırılır)

A.B.CYaklaşım için yine başka bir örnek Eclipse Bundle Versiyonudur . Eclipse demetleri dördüncü segmente sahiptir:

Eclipse'de sürüm numaraları dört (4) segmentten oluşur: 3 tamsayı ve sırasıyla adlandırılmış bir dize major.minor.service.qualifier. Her bölüm farklı bir amaç yakalar:

• büyük segment API'deki kırılmayı gösterir
• küçük segment "harici olarak görünür" değişiklikleri belirtir
• hizmet segmenti hata düzeltmelerini ve geliştirme akışındaki değişikliği gösterir
• niteleyici segmenti belirli bir yapıyı gösterir

Orada da tarih sürüm şeması , örneğin: YYYY.MM, YY.MM,YYYYMMDD

Oldukça bilgilendirici çünkü ilk bakış, çıkış tarihi hakkında bir izlenim veriyor. Ama xyz şemasını tercih ederim, çünkü her zaman bir ürünün yaşam döngüsünde tam noktasını bilmek istiyorum (Major.minor.release)

Temel cevap "O bağlıdır".

Sürüm oluşturmadaki amacınız nedir? Birçok kişi version.revision.build kullanmaktadır ve yalnızca dev.revision'u dünyaya tanıtmaktadır. Check-in 'sürüm' kullanıyorsanız sürüm numaralarınızın hızla büyüdüğünü göreceksiniz.

Projenizi planlıyorsanız, küçük değişikliklerle yapılan sürümler için revizyonu ve büyük değişiklikler, hata düzeltmeleri veya işlevsellik / özellikler içeren sürümler için yükseltme sürümünü yükseltirim. Beta veya gecelik derleme türü sürümleri sunuyorsanız, derlemeyi her sürümdeki derlemeyi ve artışı içerecek şekilde genişletin.

Yine de, günün sonunda, bu size bağlıdır ve sizin için bir anlam ifade etmelidir.

Mahesh'in dediği gibi: Xyz tür versiyonlama kullanırım

x - büyük sürüm y - küçük sürüm z - derleme numarası

belki z yerine tarih saat eklemek isteyebilirsiniz.

Başka bir sürümünüz olduğunda küçük sürümü artırırsınız. Büyük sürüm muhtemelen 0 veya 1 olarak kalacaktır, gerçekten büyük değişiklikler yaptığınızda (genellikle yazılımınız önceki sürümlerle geriye dönük olarak uyumlu olmayan bir noktada olduğunda veya tüm çerçevenizi değiştirdiğinizde)

Diğerlerinin ne yaptığını görmek için her zaman kontrol edebileceğinizi biliyorsunuz. Açık kaynaklı yazılım depolarına erişime izin verme eğilimindedir. Örneğin, SVN tarayıcınızı http://svn.doctrine-project.org adresine yönlendirebilir ve gerçek bir proje tarafından kullanılan sürüm sistemine bir göz atabilirsiniz.

Sürüm numaraları, etiketler, hepsi orada.

Abc yaklaşımını aşağıdaki gibi takip ediyoruz:

uygulamada bazı önemli değişiklikler varsa 'a' değerini artırmak. .NET 1.1 uygulamasını .NET 3.5'e yükselttiğimiz gibi

herhangi bir yeni CR veya Geliştirme uygulanmış gibi bazı küçük değişiklikler varsa 'b' artışı.

kodda bazı hata düzeltmeleri varsa 'c' değerini artırmak.

Sürümlemeye en düşük (düzeltme olmayan) segmentte başladım. Bu segmenti 10 ile sınırlamıyorum. Derlemeleri izlemediğiniz sürece, yalnızca bir artışı ne zaman uygulamak istediğinize karar vermeniz gerekir . Bir KG aşaması varsa, en düşük segmente bir artış uyguladığınız yer olabilir ve ardından KG'yi geçip serbest bırakıldığında bir sonraki segment yukarı doğru çıkabilir. Ana davranış / kullanıcı arayüzü değişiklikleri için en üstteki segmentten ayrılın.

Eğer benim gibi iseniz, bunu yazılımınızın ilerlemesinin hızına uyacak şekilde yöntemlerin bir melezi haline getireceksiniz.

Özellikle karışımda QA / Uyumluluk varsa en çok kabul edilen desen abc veya abcd olduğunu düşünüyorum. Tarih boyunca düzenli bir parçası olmak o kadar çok korktum ki ana akım için vazgeçtim.

Ben bir düzeltme dahil olmadığı sürece abc desen kullanmak istiyorum bu yüzden yapıları izlemiyorum. Bir düzeltme uygulamak zorunda kaldım sonra zaman ile tarih olarak parametre d uygulayın. Zaman parametresini d olarak kabul ettim, çünkü her zaman üretimde işlerin gerçekten patladığı bir günde birkaçının potansiyeli vardır. D segmentini (YYYYMMDDHHNN) yalnızca bir üretim düzeltmesi için ayrılırken uygularım.

Ben şahsen va.b revc yazılım programına karşı çıkmam c. YYYYMMDDHHMM veya YYYYMMDD.

Bütün bunlar söylendi. Sadece yapılandırmak ve onunla çalıştırmak için bir araç takabilirseniz , sürümün fikir yönünü sıralamak zorunda baş ağrısından koruyacak ve sadece "aracı kullanın" diyebilirsiniz ... çünkü geliştirme sürecindeki herkes genellikle çok uyumludur .