Sürüm numaraları nasıl yapılır?

Şirketim bir ürün inşa ediyor. SVN tarafından yayınlanacak. Bu bir web uygulamasıdır, temelde, içinde bazı özelliklere sahip olmayan ve dolayısıyla her zaman beta olarak etiketlenebilecek bir sürüm olmayacaktır. Ama kurumsal bir ürün olacağından, oradaki "kararsız watchout" u gerçekten istemiyorum. Peki versiyonlamaya nasıl başlarsın? 1.0 kararlı mı? Derleme tarihi sürüm numarasında olmalı mı? Bana ne düşündüğünü söyle!

[ büyük ]. [ küçük ]. [ serbest bırakma ]. [ derleme ]

major : Gerçekten bir pazarlama kararı. 1.0 sürümünü aramaya hazır mısınız? Şirket bunu müşterilerin daha fazla ödemek zorunda kalabilecekleri büyük bir sürüm olarak mı değerlendiriyor, yoksa şu anda geçerli olabilecek büyük sürümün bir güncellemesi mi? Daha az Ar-Ge kararı ve daha fazla ürün kararı.

minör : Majör arttığında 0'dan başlar . Herkese açık olan her sürüm için +1.

sürüm : Bir geliştirme kilometre taşına her bastığınızda ve ürünü dahili olarak (örneğin KG'ye) serbest bıraktığınızda, bunu artırın. Bu, özellikle kuruluştaki ekipler arasındaki iletişim için önemlidir. Söylemeye gerek yok, asla aynı 'sürümü' iki kez (dahili olarak bile) serbest bırakmayın. Küçük ++ veya majör ++ üzerine 0'a sıfırlayın.

build : Bir SVN revizyonu olabilir, bunun en iyi sonucu verdiğini düşünüyorum.

Örnekler
Mevcut kromum: 83.0.4103.61

xyzg

g'deki artışlar kararsızdır. (veya RC'ler) z'deki artışlar sabittir ve hata düzeltmeleri anlamına gelir.
y'deki artışlar sabittir ve yeni özellikler anlamına gelir.
x'teki artışlar sabittir,% 100 geriye dönük uyumluluk olmadan büyük sürümdür.

Bir zamanlar büyük bir projem için ayrıntılı bir "versiyon oluşturma tarzı kılavuzu" yazdım. Proje gerçekleştirilemedi, ancak stil kılavuzu hala çevrimiçi . Bu benim kişisel görüşüm, belki de sizin için yararlı (veya ilham verici).

Dikkat edin, bu uzun bir metindir ve ürün sürümüne ve bunun gibi şeylere karşı bileşen sürümlemeye gider. Ayrıca OSS topluluğunda popüler olan bazı versiyonlama şemaları hakkında güçlü görüşler ifade ediyor, ancak bende var, bu yüzden onları ifade ediyorum. ;-)

Örneğin, Subversion revizyon numarasını kullanmaya katılmıyorum. TRUNK'da geliştirmeye devam ederken yayınlanmış bir sürümü korumak isteyebilirsiniz, böylece bir bakım dalı kuracaksınız ve revizyon numarası sürümlemeniz boşa gidiyor.

Düzenleme: Özet olarak, kaynak dosyaları, bileşenleri ve genel ürünü sürümlendirme arasında ayrım yapar. Bileşenler ve ürün için ayrı bir xy versoning sistemi kullanır ve bu, hangi bileşen sürümünün hangi ürün sürümüne ait olduğunu izlemeyi sağlayan iki bileşen arasında hoş bir bağımlılık gösterir. Ayrıca, sistemi bozmadan alfa / beta / bırakma / yama döngülerinin nasıl ele alınacağından bahseder. Aslında, tüm geliştirme döngüsü için bir modus operandi, bu yüzden kiraz seçmek isteyebilirsiniz. ;-)

Edit 2: Yeterli kişi bu "Güzel Cevap" yapmak için makalemi yararlı buldukça, makale üzerinde tekrar çalışmaya başladım. PDF ve LaTeX sürümleri artık mevcut, daha iyi dil ve açıklayıcı grafikler içeren tam bir yeniden yazma zamanı bulur bulmaz izleyecek. oylarınız için teşekkürler!

Kendinize Wikipedia'dan ilham alın: "Yazılım sürümü oluşturma"

Başka bir "yeni" ve "nispeten popüler" seçenek Anlamsal Sürüm Oluşturma

Özet:

MAJOR.MINOR.PATCH sürüm numarası verildiğinde:

1. Uyumsuz API değişiklikleri yaptığınızda önemli sürüm,
2. İşlevleri geriye dönük uyumlu bir şekilde eklediğinizde MINOR sürümü ve
3. PATCH sürümü geriye dönük uyumlu hata düzeltmeleri yaptığınızda.

Sürüm öncesi ve derleme meta verileri için ek etiketler MAJOR.MINOR.PATCH biçiminin uzantıları olarak mevcuttur.

abcd

Artımlar: when
- d : hata düzeltmeleri
- c : bakım, örneğin performans iyileştirme
- b : yeni özellikler
- a : mimari değişiklik

Zorunlu olan en sol olanıdır, örneğin yeni bir özellik ve bir hata düzeltilmişse, sadece b'yi arttırmanız gerekir .

Karmaşık kurumsal platform düzeyinde bağımlılık yönetimi ve sürüm sürümü oluşturma konusundaki deneyimlerime dayanarak Yarı Semantik Sürüm Oluşturma adını vermeyi düşündüğüm bir yaklaşım önermeye geldim .

Temel olarak Semantic Versioning 2.0'dan oluşur, ancak o kadar da katı değildir.

Yarı Semantik Versiyon Segmentleri:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Birincil Sürüm Segment Biçimi:

MARKETTING.MAJOR.MINOR.PATCH

Her bölüm alfasayısallara izin vermelidir, ancak mantıksal artımlı değişiklikler için saf sayısallar önerilir.

SemVer gibi, Major, Minor ve Patch bileşenlerini ters uyumluluk katmanlarını temsil etmelerini öneriyorum, ancak bir Marketing bileşenini de eklemenizi tavsiye ediyorum . Bu, ürün sahiplerinin, özellik destanlarının / gruplarının ve ticari kaygıların, teknik uyumluluk kaygılarından bağımsız olarak birincil bileşeni çarpmasına izin verir.

Diğer yanıtların aksine, birincil segmente bir Yapı numarası eklemenizi önermiyorum. Bunun yerine, bir '+' işaretinin ardından Yayın Sonrası Segment ekleyin (ör: 1.1.0.0 + derleme.42). SemVer bu derleme meta verilerini çağırıyor, ancak Post-Release Segment'in daha net olduğunu düşünüyorum. Bu segment, son Sürüm verilerini birincil Sürüm Segmentindeki uyumluluk bilgileriyle ilgili olmadığı bildirmek için mükemmeldir. Daha sonra sürekli entegrasyon derlemelerinize, her bir birincil sürümden sonra sıfırlanan artımlı bir derleme numarası eklenmiş önceki sürüm numarası verilebilir (ör: 1.1.0.0 -> 1.1.0.0 + derleme 1 -> 1.1.0.0 + derleme 2 -> 1.1.0.1). Bazı insanlar dönüşümlü olarak svn revizyon numarasını veya git deposunu kod deposuna bağlamayı kolaylaştırmak için koymak isterler. Başka bir seçenek, düzeltmeler ve düzeltme ekleri için sürüm sonrası segmentini kullanmaktır, bunun için yeni bir birincil sürüm bileşeni eklemeye değer olabilir. Yama bileşeni artırıldığında her zaman bırakılabilir, çünkü sürümler etkili bir şekilde sola hizalanır ve sıralanır.

Serbest bırakma ve serbest bırakma bölümlerine ek olarak, insanlar genellikle alfalar, betalar ve serbest bırakma adayları gibi neredeyse istikrarlı ön sürümleri belirtmek için bir Ön Sürüm Segmenti kullanmak isterler. SemVer yaklaşımı iyi çalışır, ancak sayısal bileşenleri alfa-sayısal sınıflandırıcılardan ayırmanızı öneririm (örn: 1.2.0.0 + alpha.2 veya 1.2.0.0 + RC.2). Normalde, serbest bırakma segmentini serbest bırakma sonrası segmentini eklerken aynı anda çarptıracak ve daha sonra bir sonraki serbest bırakma segmentini çarptığınızda serbest bırakma segmentini bırakacaksınız (ör: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Sürüm öncesi segmentler, sürüm sürümünün geldiğini belirtmek için eklenir; genellikle, daha fazla işleme bağlı olarak dakikadan dakikaya değişmeyen daha ayrıntılı test ve paylaşım için yalnızca sabit bir özellik grubu.

Bunların hepsini semantik olarak neredeyse tüm kullanım durumlarını kapsayacak şekilde tanımlamanın güzelliği, bunları standart bir şekilde ayrıştırabilir, sıralayabilir, karşılaştırabilir ve artırabilirsiniz. Bu, özellikle her biri kendi yönetilen bağımlılıklarına sahip bağımsız olarak küçük çok sayıda bileşen (mikro hizmetler gibi) içeren karmaşık uygulamalar için CI sistemleri kullanıldığında özellikle önemlidir.

Eğer ilgileniyorsanız, Ruby'de yarı-anlamsal bir ayrıştırıcı yazdım . Sadece bu kalıbı kullanmam gerekiyordu, aynı zamanda onu kullanan diğer uygulamaları da yönetebilmeliydim.

"Sürüm numaraları" dahili sürüm kontrol sisteminiz için önemlidir. Sürüm numaraları farklı bir konudur (ve KEPT farklı olmalıdır).

MAJOR'un uyumluluk seviyesi olduğu basit bir MAJOR.MINOR yayın sistemine (v1.27 gibi) sadık kalın (sürüm 2.x sürüm 1.x ile uyumsuz veya en azından büyük ölçüde farklıdır) ve MINOR hata düzeltme sürümleriniz veya küçük geliştirmelerdir . XY biçimini izlediğiniz sürece YEAR.MONTH (2009.12) veya YEAR.RELEASE (2009.3) gibi diğer sistemleri de kullanabilirsiniz. Ama gerçekten iyi bir nedeniniz yoksa MAJOR.MINOR'a bağlı kalın.

Kesinlikle XY biçimine uymayan bir şey kullanmayın, çünkü dağıtımların, duyuru web sitelerinin vb. Sizinle çalışmasını zorlaştıracaktır ve bu sadece projenizin popülaritesini ciddi şekilde etkileyebilir.

Belirli dahili sürüm numaralarını sırasıyla MAJORS ve MINORS ile ilgili olarak işaretlemek için (tercihen dağıtılmış) sürüm kontrol sisteminizdeki dalları ve etiketleri kullanın.

Ve evet, 1.0 kararlı olmalı. Alfa, beta veya RC olarak işaretlenmedikçe tüm sürümler sabit olmalıdır. Bilinen-kırık ve eksik için Alfa kullanın. Betas bilinen-kırık için. "Denemek; muhtemelen kaçırdığımız şeyleri fark edeceksiniz" için RC'ler. Bunlardan biri olmayan her şey (ideal olarak, elbette) test edilmeli, iyi bilinmeli, güncel bir el kitabına vb. Sahip olmalıdır.

Subversion revizyon numarasını kullanmak bugünlerde oldukça popüler.

SVN'deyse neden SVN revizyon numarasını kullanmıyorsunuz?

Bu web sayfasının sağ alt kısmına bakarsanız, SVN revizyon numarası olan Stack Overflow sürüm numarasını görürsünüz.

Sürüm oluşturma size bağlıdır; Kendime güvendiğim ilk versiyona 1.0 koydum. Bazı yazılım satıcıları 1.0'a kötü bir üne sahip olduğundan, diğer versiyonlarla hızlı bir şekilde takip etmek isteyebilirsiniz.

Sürüm numarasını kullanılan tam yapıya bağlamanın bir yolunu istiyorsunuz, ancak muhtemelen son kullanıcılarınız için güzel ve basit olmasını istiyorsunuz. Standart sürüm numaralarını kullanmayı ve SVN deposunu dahil edilen sürüm numarasıyla etiketlemeyi düşünün.

Sadece Subversion revizyon numarası ile gitmek güzel ve basit olsa da, sürüm numarasından bilgi kaldırır. Kullanıcılar bunun kötü bir şey olduğunu düşünebilir.

Web uygulamanızın bir tür dağıtım prosedürüne sahip olacağını varsayıyorum, böylece Subversion'daki her bir revizyon aslında yayınlanmıyor. "Dışarıdan" (kullanıcının bakış açısından) ne zaman yayın yapıldığını ve kodun aralarında kaç revizyon yapılacağını belirlemek imkansız olduğundan, sayıları neredeyse rastgele yapar. Artacaklar ve sanırım iki revizyonu karşılaştırmaktan biraz uzaklaşmak mümkün , ama fazla değil.

Klasik sürüm numaraları, sürümleri "dramatize" etme eğilimindedir, böylece kullanıcılar bir tür beklenti oluşturabilir. Düşünmek daha kolay "Ben sürüm 1.0 var, şimdi sürüm 1.1 bunu ekleyerek ve bu ilginç geliyor" düşünmek daha "dün biz SO revizyon 2587 koştu, bugün 3233, çok daha iyi olmalı!"

Tabii ki, bu dramatizasyon da şişirilebilir, şirketteki gerçek farklılıklar tarafından motive olandan daha ilginç gelmesi gereken sürüm numaralarını seçen şirketler ile, sanırım revizyon numarası sayaçlarıyla bu biraz gidiyor.

Sürüm şeması: [ana]. [Küçük]. [Devrel] [mark]
[ana]: Gelişmede büyük bir değişiklik varsa artırın .
[minör]: gelişimde ufak bir değişikliğiniz varsa artırın.
[devrel]: hata düzeltmeniz varsa artırın. Major ++ veya minor ++ ise sıfıra sıfırlayın.
[mark]: a, b veya rc: a bir alfa sürümü, b beta sürümü ve rc bir sürüm adayıdır. 1.3.57a veya 1.3.57b veya 1.3.57rc gibi sürümlerin sürüm 1.3.57'den önce olduğunu unutmayın. 0.0.0'da başlayın.

Ana sürümü ne zaman artıracağınıza karar vermek için çok fazla zaman harcadık. Bazı dükkanlar nadiren bunu yapar, böylece 1.25.3 gibi sürümler alırsınız ve diğerleri size 15.0 veren hiç yayınlamak için yapar

Bundan bıktım ve herkese büyük sürümün sadece yıl olduğunu ve minörün yıl içinde sıralı bir sürüm olduğunu ikna ettim. Kullanıcılar beğenmiş gibi görünüyordu ve bir sonraki sürüm numarası ile gelmek beyinsiz.

Year.Release.build

• yıl = cari yıl
• release = yeni işlevlere sahip herkese açık sürüm sayısı # - her yıl 1'e sıfırla
• build = hata düzeltmeleri ve dahili sürümler için artırıldı

DÜZENLE

** Şimdi bu sürekli geliştirilmiş bir dahili uygulama içindi **

Bu, muhtemelen pazarlama ve finansal amaçlar için yılın farklı zamanlarında büyük sürümlerin bulunmasının önemli olduğu ticari uygulamalar için işe yaramayacaktır.

Bu sorunun var olmasının nedeni, yapılandırma yönetimi yapmak için üzerinde anlaşmaya varılmış tek bir yolumuz olmamasıdır.

Sürüm numarasını yapmak istediğim şekilde tamsayıyı 1'den arttırmak. Açıklamak veya belgelemek zorunda kalacağım çok parçalı bir sürüm numarası istemiyorum. Ve SVN rev numarasını kullanmak istemiyorum, çünkü bu da biraz açıklamayı gerektirecek.

Bunu yapmak için SVN'nin üstünde bazı yayın komut dosyalarına ihtiyacınız olacak

Bölgede çok az deneyimim var. Ancak, ben ne yapacağım:

1. Düzeltmeleri numaralandırmak için bir şema seçin ve ona sadık kalın. Tutarlı olun.
2. Her sürüm değişikliği önemli bir değişikliği temsil etmelidir . Bir değişikliğin ne kadar küçük olduğu ve sürüm numarasına yansıyan değişiklik seviyeleri size bağlıdır.

Tabii ki, sadece svn revizyon numarasını kullanabilirsiniz - diğerleri gibi önerdi !!!

Umarım bu yardımcı olur.

Basit bir major.minor.julian_date sözdizimi kullanıyoruz.

Nerede;

• major - İlk sürüm 1'dir ve daha sonra önemli yeni özellikleri veya değişiklikleri bu kadar önemli hale getirdiğimizde geriye dönük uyumlu olmadıklarında bu sayıyı artırın.
• minör - Önemli kilometre taşı bültenleri. Üretimle itilen her yapı için bu sayı artar.
• julian_date - Yapının QA'ya gönderildiği Jülyen Günü .

1/15 tarihinde KG'ye itilen ilk sürüm
örneği -> 1.0.015 3/4 tarihinde Üretime itilen ilk sürüm örneği -> 1.1.063

Mükemmel değil, ama her gün QA'ya inşa ettiğimiz için kullanışlı.

Burada bazı iyi bilgiler:

Dosya / Montaj Sürümleri Ne Zaman Değiştirilir

Her şeyden önce, dosya sürümleri ve derleme sürümlerinin birbiriyle çakışması gerekmez. Dosya sürümlerinin her derlemede değişmesini öneririm. Ancak, aynı dosyanın iki sürümü arasındaki farkı anlayabilmeniz için derleme sürümlerini her derlemeyle değiştirmeyin; bunun için dosya sürümünü kullanın. Montaj sürümlerinin ne zaman değiştirileceğine karar vermek, dikkate alınacak yapı türleri hakkında biraz tartışmaya neden olur: nakliye ve nakliye dışı.

Gönderim Dışı Yapılar Genel olarak, gönderim yapmama sürümleri arasında gönderim dışı montaj sürümlerini aynı tutmanızı öneririm. Bu, sürüm uyuşmazlıkları nedeniyle kesin olarak adlandırılmış derleme yükleme sorunlarını önler. Bazı kişiler, her derleme için yeni derleme sürümlerini yeniden yönlendirmek üzere yayıncı ilkesini kullanmayı tercih eder. Bununla birlikte, nakliye dışı derlemeler için buna karşı öneriyorum: tüm yükleme sorunlarından kaçınmıyor. Örneğin, bir iş ortağı uygulamanızı x kopyalarsa yayıncı politikasını yüklemeyi bilemeyebilir. Ardından, makinenizde iyi çalışıyor olsa bile, uygulamanız onlar için kırılacaktır.

Ancak, aynı makinedeki farklı uygulamaların montajınızın farklı sürümlerine bağlanması gerektiği durumlar varsa, her bir uygulama için doğru olanın LoadFrom / etc'yi kullanmak zorunda kalmadan kullanılabilmesi için bu yapılara farklı montaj sürümleri vermenizi öneririm.

Gönderi Derlemeleri Gönderi derlemeleri için bu sürümü değiştirmenin iyi bir fikir olup olmadığı, bağlamanın son kullanıcılar için nasıl çalışmasını istediğinize bağlıdır. Bu yapıların yan yana veya yerinde olmasını ister misiniz? İki yapı arasında birçok değişiklik var mı? Bazı müşterileri kıracaklar mı? Bunları bozduğunu düşünüyor musunuz (veya kullanıcıları önemli güncellemelerinizi kullanmaya zorlamak mı istiyorsunuz)? Evetse, montaj sürümünü artırmayı düşünmelisiniz. Ancak, yine, bunu defalarca yapmanın, kullanıcının diskini eski derlemelerle doldurabileceğini düşünün.

Derleme Sürümlerinizi Değiştirdiğinizde Sabit kodlanmış sürümleri yenisiyle değiştirmek için, bir başlık dosyasındaki sürüme bir değişken ayarlamanızı ve kaynaklardaki sabit kodlamayı değişkenle değiştirmenizi öneririz. Ardından, doğru sürümü koymak için derleme sırasında bir ön işlemci çalıştırın. Değişiklikleri nedeniyle hataları yakalamak için daha fazla zaman olması için, gönderildikten hemen sonra sürümleri değiştirmenizi öneririz.

Veya 'düşünce' sürüm numaranızı virgül altyazı numaranızı kullanmak için .. zB:

1.0.101 // revizyon 101, sürüm

veya 1.0.101-090303 // çıkış tarihi ile bunu kullanıyorum