Ana / küçük / yama sürüm numaranızı ne zaman değiştirirsiniz?

Olası Çoğalt:
Hangi “sürüm adlandırma kuralı” nı kullanıyorsunuz?

Başlıca / küçük / yama sürüm numaralarınızı serbest bırakmadan hemen önce veya hemen sonra değiştiriyor musunuz?

Örnek: Dünyaya sadece 1.0.0 yayınladınız (huzzah!). Ama bekle, çok fazla kutlama. 1.1.0 altı hafta içinde çıkıyor! Böylece bir hatayı düzeltir ve yeni bir yapı oluşturur. Bu inşaa ne denir? 1.1.0.0 veya 1.0.0.xxxy (nerede xxxy 1.0.0 artırılmış yapıdır)?

1.1.0'a girecek 100 özelliğin ve hatanın olabileceğini unutmayın. Bu nedenle, 1.0.0.xxxy'yi çağırmak iyi olabilir, çünkü 1.1.0'a hiçbir yere yakın değilsiniz. Ancak öte yandan, 2.0.0 üzerinde çalışan başka bir dev de olabilir; bu durumda yapınız sırasıyla 1.0.0.xxxy ve 1.0.0.xxxz yerine 1.1.0.0 ve onun 2.0.0.0 olarak adlandırılabilir.

Yazılımınızı bıraktıktan sonra, sürüm numarası hemen artırılmalıdır.

Neden?

Anlamsal Sürüm Oluşturma gibi bir şema izlediğinizi ve sürümde bir yapı numarasına sahip olduğunuzu varsayalım . Yani [Major]. [Minor]. [Patch]. [Build] olabilir. Sürümün [Major]. [Minor]. [Patch] bölümlerini arayacağım.

Geliştirme sırasında birden fazla yapı oluşturacaksınız. Her derleme, bir sonraki sürümünüzün bir geliştirme görüntüsüdür. Geliştirme ve sürüm oluşturma işlemleriniz için aynı sürümü kullanmanız mantıklıdır. Sürümü nasıl dans ettiğini serbest gösterir doğru .

Yayınlamaya hazırlanıyorsanız ve yazılım tüm testlerini geçerse, sürümü güncellemeniz gerektiğinden yazılımı yeniden oluşturmak ve yeniden test etmek istemeyeceksiniz. Sonunda bir sürüm yaptığınızda, "build 1.1.0.23" ifadesinin bundan böyle "sürüm 1.1.0" olarak anılacağını belirtiyorsunuz.

Artış sonrası salım modeli dallanma için de anlamlıdır. Bir ana hat geliştirme şubesine sahip olduğunuzu ve sürümler için bakım dalları oluşturduğunuzu varsayalım. Yayın dalınızı oluşturduğunuz anda, geliştirme dalınız artık o yayın sürüm sürümüyle bağlantılı değildir. Geliştirme dalı, bir sonraki sürümün bir parçası olan kod içerdiğinden, sürümün bunu yansıtması gerekir.

Genelde dahili sürüm numaraları için SemVer kullanmaya çalışıyorum . Sürüm numarasının anlamını temel alan bir sürüm hakkında bir şeyler bilmek güzel.

Geliştirme sırasında, sürüm numaralarını hemen değiştirmeye çalışıyorum (mümkünse) . Bazen değişimin kırılmayacak bir değişiklik olup olmayacağını bilmek zor (sürüm numaramı etkileyecek), bu nedenle hiçbir şey "taşa yerleştirilmemiştir".

Özel örneğinizi ele almak için:

• Geliştirme sırasında, sürüm öncesi sürümler 1.0.1-alpha.1, 1.0.1-alpha.2 vb. Olacaktır.
• Hata düzeltmesinin son sürümü sürüm 1.0.1 olacaktır.

'Halka açık' ürün sürümü numaralarının genellikle pazarlama tarafından belirlendiğini ve tamamen farklı olduklarını söyleyerek. Bu benim kontrolüm dışında, bu yüzden endişelenmenize gerek yok.

Cevaplarda ABCD varsayalım. Her bir bileşeni ne zaman arttırıyorsunuz?

Temelde şirket politikanız tarafından belirlenir. Şirket politikamız:

• A - İşlevsellik veya arayüzde önemli (>% 25) değişiklikler veya eklemeler.
• B - işlevsellik veya arayüzde küçük değişiklikler veya eklemeler.
• C - arayüzü bozan küçük değişiklikler.
• D - arayüzü değiştirmeyen bir yapıya giderir.

Daha büyük projelerde / organizasyonlarda, ana ve küçük sürüm numaraları pazarlama departmanları tarafından kontrol edilir ve genellikle pazarlama nedeniyle artırılır. Organizasyonumda gruplar her yıl bir büyük ve bir küçük serbest bırakmayı hedefliyor. Beklenti, büyük sürümlerin önemli yeni işlevler içermesi ve aynı büyük sürüm numarasına sahip tüm sürümler için API'ler arasında ikili uyumluluk olmasıdır. Bununla birlikte, pazarlama vaat edilen özellikler yerine getirilmediğinden veya örneğin kurbağa rekabetini atlattığı görüldüğü için tersine, büyük bir versiyon değişikliğini küçültmeyi tercih edebilir.

Büyük ve küçük yapım sayıları (abcd'deki c ve d) genellikle geliştirme ile kontrol edilir. c, yapı numarasıdır ve d, c'nin belirli bir sürümündeki ya da sürümündeki yamalar için kullanılır.

Sizin durumunuzda, büyük ve küçük sürüm numaralarını değiştirdiğinizde, büyük ve küçük yapı numaralarının doğru olmasını sağlamaktan daha az ilgili olur. Organizasyonumda, kaynak kontrolündeki dallanma sürecinin bir parçası olarak ana ve küçük yapım sayılarını değiştiriyoruz. Ana dal genellikle en son sürümü içerir ancak pazarlama, sürümün henüz hangi sürüm numarasına sahip olacağına karar vermemiş olabilir.

Eclipse örneğini izlemeye çalışıyoruz . Açıklayabileceğimden daha iyi bir açıklama yapıyor, ama bizim için etkili bir şekilde şöyle çalışıyor:

1.0.0.0 yayımladığınızda, değiştireceğiniz sürüm numarası yaptığınız değişiklik türüne bağlıdır.

• API'yi etkilemeyen bir sürüm, geçerli API'nin beklenen şekilde çalışmasını sağlayan sahne hatalarının giderilmesini arkası düşünün 1.0.1'de yayımlandı.
• API'ye ekleyen, ancak mevcut API'yi değiştirmeyen bir sürümde, mevcut müşterileri yeni sürümle karşılaştırılamaz kılan yeni bir özellik eklenmiş olabilirsiniz. Bu, yukarıdaki düzeltmelerden herhangi bir sayıda içerebilir.
• Bir sürüm, mevcut API ile karşılaştırır, bir şeyi kaldırır, bir şeyleri değiştirerek mevcut müşterilerle karşılaştırılabilirliği bozacak şekilde değiştirir. Bu, yukarıdaki düzeltmelerden herhangi birine de sahip olabilir.

Sürüm numarasında 4. bölümün nasıl kullanılacağına gelince, bunu Nuget'teki farklı yapıları ayırt etmek için kullanıyoruz (.net için kullandığımız paket yönetimi çözümü). Bu, yayınlanmamış yazılımımızı güncellememiz gerektiğinde önbellekleri temizlemek zorunda kalmamamızı sağlar.

Bir sonraki yapı yok. O dalda.

Programımızın idealleştirilmiş hali.

Herhangi bir şubedeki sürüm kimliği PRETTY_BRANCH_NAME-build ve PRETTY_BRANCH_NAME şube oluşturma işleminde sabitlendi.

Dallanma şemamız (*) aşağıdaki gibidir:

Üst düzey şubeler, her birinin PRETTY_BRANCH_NAME bir kod adı, bu düzeyde sürüm numarasının konuşması anlamsız, planlı bir şema olabilir, ancak sürümden önce değişecek.

• uzun vadeli gelişme yapılan bir TNG ( yeni nesil ) şubesi. Genelde bizde bile yoktur ve hiçbir zaman alt dallara sahip değildir.

• Mevcut gelişimin yapıldığı bir TCG ( şimdiki nesil ) şubesi. PRETTY_BRANCH_NAME bir kod adıdır.

• bir TPG ( önceki nesil ) dalı. Genellikle burada daha fazla gelişme yapılmaz, ancak alt dallarda etkinlik olabilir.

Bir ana dallanma için beta olduğunda bir alt dal üst düzey bir daldan (TPG'nin yavaş TPG geçişi varlığında) yapılır. PRETTY_BRANCH_NAME, "1.3.X" gibi bir şey (X, harf değil, rakam değil, buradan 1.3 sürüm yayınlama niyetindeyiz), beta sürümünden gelen geri bildirimler burada bir sonraki ana sürüm için çalışma yapılırken dikkate alınır. TCG şubesi.

İdeal olarak, sürüm bu dalda anlık olmalıdır, ancak mükemmel olmadığımızı ve diğerlerinin sonraki küçük sürüm için çalışmaya devam etmelerine izin verirken son dakika değişiklikleri yapmamız gerektiğini biliyoruz. Böylece, alt isimler, "1.3.X" şubesinden "1.3", "1.3.1" gibi "1.3", "1.3.1" gibi resmi sürüm numarası olan güzel isimlerle son stabilizasyon için yapılmıştır. Her biri üzerinde son yapı, sürümdür.

Eğer dördüncü bir seviyeye sahip olsaydık, alt şubelerin adları "1.3.0." "1.3.0.1" alt alt grubumuz olan "1.3.0.X" olurdu.

(*) Serbest bırakma seviyesinde. Bunların her birinde proje alt dalları olabilir.

Yazılım satıyorsanız, satış / pazarlama daha büyük bir bonus kazanması gerektiğinde yeni bir ana sürümünüz olacak :-).

Bazı kontrolleriniz varsa o zaman:

1. Ne zaman ana bültenleri:

   • Python 2'den Python 3'e gibi dönüştürme vb. Gerektiren önceki sürümle bazı uyumsuzluklar var.

   • Bir sürü yeni işlev var.

2. İşlevsellikteki küçük değişiklikler için küçük sürümler.

3. Hata düzeltmeleri için düzeltme eki sürümü.