MAJOR.MINOR.BUILDNUMBER.REVISION içindeki yapı numarası tam olarak nedir?

Derleme Numaraları hakkında düşündüğüm şey, ne zaman yeni bir gece derlemesi oluşturulduğunda, yeni bir BUILDNUMBER üretilip bu yapıya atanması. Yani 7.0 sürüm uygulamam için, gece yapılan sürümler 7.0.1, 7.0.2 vb. Olacaktır. Öyle mi? Öyleyse, derleme numarasından sonra REVISION kullanımı nedir? Yoksa REVISION kısmı her gece inşaatından sonra artırılıyor mu? Burada biraz kafam karıştı ... her gece bir yapı olarak BİNA olarak mı bahsediyoruz ?

Format burada belirtilmiştir: AssemblyVersion - MSDN

Bu şekilde yazıldığını hiç görmedim. Çalıştığım yerde, MAJOR ana bir sürüm olduğu MAJOR.MINOR.REVISION.BUILDNUMBER biçimini kullanıyoruz, MINOR küçük bir sürümdür (genellikle kullanıcı arayüzünde veya altta yatan işletim sisteminde birçok yeni özellik veya değişiklik), MINOR küçük bir sürümdür (belki de bazı yeni özellikler). önceki bir büyük sürüm olan REVISION genellikle önceki bir küçük sürüm için bir düzeltmedir (yeni işlevsellik içermez) ve revizyonun her yeni sürümü için BUILDNUMBER artırılır.

Örneğin, QA'da (kalite kontrol) bir revizyon yayınlanabilir ve değişiklik gerektiren bir sorunla geri dönerler. Hata düzeltildi ve aynı REVISION numarasıyla ancak artan bir BUILDNUMBER ile birlikte QA'ya bırakıldı.

Tüm karışıklık , MS'in "Yapı numarası" ve özellikle de "Düzeltme" için kullandığı farklı anlambilimden kaynaklanmaktadır . Terimler sadece farklı şeyler ifade eder.

Çoğu kişi (kendim dahil) , ne olursa olsun yeni bir yapı oluşturmak zorunda kaldığınızda daha yüksek bir YAPI numarası aldığınız semantik bir sürüm numaralandırma şeması kullanır . Bizim için bir düzeltme sadece başka bir kod değişikliği olarak kabul edilir ve BUILD kısmı her CI çalışmasında otomatik olarak artar. Aynı MAJ.MIN.REV olan modüller birbirinin yerine geçebilir sayılır ve BUILD size hangisinin en yeni olduğunu söyler.

Ancak REVISION değerini artırmak, yeni bir kalıcı sürüm şubesi olduğunu gösterir, bu yüzden BUILD'tan önce yerleştiririz. Bu yaklaşımın dezavantajı, aşağıdaki olaylar dizisini elde edebileceğimizdir:

• taahhüt numarası 4711: Alice, A özelliğini ekledi
• CI 1.2.3.100 yapı üretti
• taahhüt numarası 4712: Bob, B özelliğini değiştirdi
• taahhüt numarası 4713: Alice, A özelliği düzeltildi ("düzeltme")
• CI 1.2.3.101 yapı üretti

Gördüğünüz gibi, düzeltme bir sonraki derlemede içerilen tek değişiklik değil, aynı zamanda Bob'un modifikasyonu bu derlemenin bir parçası haline geldi. Mevcut şubeyi dengelemek istiyorsanız, Bob'un bir demet böcek ekleyip eklemeyeceğinden asla emin olamadığınız için sıkıntılarla karşılaşabilirsiniz.

MS her iki terimi de farklı kullanır. YAPI numarası otomatik olarak artırılmaz, bunun yerine, kodun belirli bir sürümü için kullanılan kodu dondurmak için bir tür yayın dalı olarak kabul edilebilir. REVISION, bu YAPI dalına uygulanan ek "sıcak" değişiklikleri gösterir. Bu nedenle dizi şöyle olacaktır:

• taahhüt numarası 4711: Alice, gövde / anaya A özelliğini ekledi
• Carl yapı dalı oluşturuyor 1.2.100
• CI 1.2.100.0 yapı üretir
• taahhüt numarası 4712: Bob gövde / ana biriminde B özelliğini değiştirdi
• taahhüt numarası 4713: Alice, 1.2.100dalda A özelliğini sabitledi
• CI 1.2.100.1 yapı üretir

REVİZYON terimi,

• Bir ürün revizyon (işte çoğu insan bunu nasıl kullandıkları)
• Belirli bir günlük yapının revizyonu ( MS'in yaptığı)

İki işlem arasındaki temel fark, CI yapılarına düzeltmeler uygulayıp uygulayamayacağınız ve bu nedenle dalın hangi aşamada yapıldığıdır. Bu özellik, tüm testler başarıyla tamamlandıktan sonra herhangi bir zamanda belirli bir yapı seçebilmek ve ürününüzün bir sonraki resmi sürümüne tam olarak bu sürümü tanıtmak istediğinizde önem kazanmaktadır.

Bizim durumumuzda CI aracı bir depo etiketi oluşturur, dolayısıyla gerektiğinde kullanıma hazır gerekli bilgilere her zaman sahibiz. SVN ile daha da kolaylaşır, çünkü etiketler ve dallar aynı şekilde uygulanır - bir etiket, altta bulunan bir daldan başka bir şey değildir /tags.

Ayrıca bakınız

TFS dallanma stratejisindeki SSS bölümünden :

Hangi şubede P1 (düzeltme) biletini düzeltmeliyim?

• P1, Üretimde çalışan kod tabanına en yakın olan dalda sabitlenmelidir. Bu durumda P1 Prod dalına sabitlenmelidir. Düzeltmeyi başka bir branşta uygulayarak ve üretimdeki değişiklikleri uygulayarak, sonraki bitimden yarı mamul veya test edilmemiş kodu serbest bırakma riski vardır.

• Şimdi doğrudan Prod şubesine karşı çalışmanın güvenli olup olmadığını, bir kez daha düşünün, acil dikkat gerektiren bir P1'in sistemde temel bir sorun olmaması gerektiğini savunabilirsiniz. Temel bir sorun olması durumunda, Müşteri ile daha fazla analiz ve tartışma gerektirebileceği için Ürün biriktirme listesine eklenmelidir.

Bir başka iyi okuma da TFS dallanma rehberidir.

Microsoft, .NET sürüm numarasının her bir bileşeninin amacını, Versionsınıf için MSDN belgelerinde açıklar . İşte ilgili kısım:

major.minor [.build [.revision]]

Bileşenler aşağıdaki şekilde kongre tarafından kullanılır:

Büyük: Aynı ada sahip ancak farklı büyük sürümler için montajlar birbiriyle değiştirilemez. Daha yüksek bir sürüm numarası, geriye dönük uyumluluğun kabul edilemeyeceği bir ürünün temel bir yeniden yazıldığını gösterebilir.

Küçük: İki derlemedeki isim ve ana sürüm numarası aynıysa, ancak küçük sürüm numarası farklıysa, bu geriye dönük uyumluluk niyetiyle önemli bir iyileştirme olduğunu gösterir. Bu daha küçük küçük versiyon numarası, bir ürünün bir nokta sürümünün veya bir ürünün tamamen geriye dönük uyumlu yeni bir versiyonunu gösterebilir.

Yapı: Yapı sayısındaki fark, aynı kaynağın yeniden derlenmesini temsil eder. İşlemci, platform veya derleyici değiştiğinde farklı yapı numaraları kullanılabilir.

Revizyon: Aynı isimde, ana ve küçük versiyon numaralarına sahip montajlar, fakat farklı revizyonların tamamen değiştirilebilir olması amaçlanmıştır. Daha önce yayımlanan bir derleme içindeki bir güvenlik deliğini düzelten bir yapıda daha yüksek bir revizyon numarası kullanılabilir.

http://msdn.microsoft.com/en-us/library/system.version.aspx

En az bir referans numarası referansını hayal edebileceğim farklı şeyler var:

1. Yayınlanan kaynak kontrol sürümü. Örneğin, # 12345 revizyonunun bir sürümünün yayınlanması durumunda, bu, derleme numarası olması ve izlenmesi gereken ya da küçük sürümleri artıracak yeni bir işlevsellik olmadığı için revizyonların yapılabileceği bir yer olması durumunda izlenebilir. ve birisinin bu yapıyı yeniden çalıştırmak istemesi durumunda derleme numarasının hatırlanması gerekir.

2. Sürekli entegrasyon sunucusu Tanımlayıcısı. Bu durumda, CI sunucusu çalıştığı her yapıyı numaralandırabilir ve bu nedenle yapı numarası başarılı bir derlemenin aldığı şeydir ve bu senaryoda revizyon bölümüne ihtiyaç duyulmaz.

Bilmediğim başkaları da olabilir, ancak bunlar kod tabanlarındaki sayılar söz konusu olduğunda bildiğim en büyükler.

Bir yapı numarası genellikle her yapı için artırılır, bu nedenle benzersizdir.

Sadelikler uğruna, bazı MAJOR veya MINOR numaraları çarpıldığında yapı numarasını sıfırlar.

Sürekli Entegrasyon motorlarının çoğu, otomatik olarak oluşturulmuş benzersiz yapı numaralarına izin verir.

Revizyon, yapıların yamalarında kullanılabilir. Diyelim ki 2 ekip bir ürün üzerinde çalışıyor.

Takım 1, ana geliştirme ekibidir ve X'in artırıldığı aşağıdaki sürüm şema 1.0.X.0 ile her gece inşa oluşturur. Şimdi inşa ediyorlar 1.0.50.0 Team 2 zaman zaman inşa ediyor. Diyelim ki yapıyı geçen hafta 1.0.43.0'dan alıyorlar ve kullanmaya başlıyorlar. 1. takım 1.0.43.0'da bir sayı bulduğunda 1. takım 1.0.51.0'a yükseldi.

Şimdi 1. takım bu yapıyı alacak (43), sorunu çözecek ve 2. takıma 1.0.43.1 derlemesini verecek. Düzeltme ana yapıya da yayılabilir, bu nedenle değişiklik 1.0.52.0'da görünecektir.

Umarım bu açık ve yardımseverdir.

* Projeye dahil olan herkes aynı yapıyı kullanmıyorsa ve belirli yapıları yamalamanız gerektiğinde revizyon faydalıdır.

Sadece nasıl gördüğümü ve kullandığımı söyleyeyim ....

ProgramAdı sürümü major.minor.build.revision

Binbaşı: Benim için üzerinde çalışmakta olduğum mevcut proje. Aynı program adında yeni bir projeye başlayana kadar bu sayı değişmeyecek. Bu, kelimenin tam anlamıyla aynı cinsiyetten yeni bir program yazacağım anlamına gelir (örneğin: erişim v1 - erişim v-2 - erişim v-3 * aynı program ancak tamamen yeniden yazılmıştır).

minor: Bu, mevcut yayınlanan projeye işlevsellik kattığım anlamına geliyor. Mesela bir makbuz basma kabiliyeti veya resim alma kabiliyeti ekledim. Temelde ek işlevsellik Şimdi eklemek istiyorum ve bir sonraki ana sürümün bunu yapmasını beklemiyorum.

yapı: Bu, yayınlanan major.minor sürümündeki çok küçük değişiklikleri belirtmek için kullanıyorum. Bu, düzende, renk düzeninde vb. Bir değişiklik olabilir.

revizyon: Bu, şu anda yayınlanan major.minor.build'deki bir hatayı düzeltmek için kullanıyorum - Mevcut projeyi ilerletmediğim ve bir hatanın ortaya çıktığı durumlar var. Bu hatanın düzeltilmesi ve yayınlanması gerekiyor. Bu, düzgün çalışması için zaten yayınladığım şeyi düzelttiğim anlamına geliyor. Bunu yeni bir derleme, yeni bir ekleme veya yeni bir büyük sürüm başlatmaya çalıştığımda da kullanırdım. Yayımlanan versiyonun bir sonraki ana, küçük veya yapım sürümü için beklemede iken yamalı olması gerekiyor.

Böylece, bu şekilde bitmiş veya duraklatılmış bir proje bir sonraki sürüm yayınlanana kadar hala sabitlenip kullanılabilir duruma getirilebilir.

Umarım bu, bu tür bir versiyonlandırmanın nasıl çalışacağı (veya çalışması gerektiği) hakkında daha iyi bir anlayış sağlar. Bana göre bu tür bir versiyonlama kullanılırken herhangi bir gerçek anlam ifade eden tek tanım ve pratiktir.

Bir sürüm numarasını yalnızca sürüm kimliğindeki son sayı olarak gördüm. Bir yapı numarasına nasıl revize edileceğinden emin değilim. Sanırım, belki de inşa edilmemiş kaynaklardan bazılarını (simgeler, DB betiği, vb.) Değiştirdiyseniz, ancak son zamanlarda üzerinde çalıştığım çoğu projenin sürüm kontrolü altındaki tüm bu şeylere sahip olması, bu nedenle derleme işlemi bunları gerçekleştirdiğinde yükleyici / serbest bırakma. Zaman damgalı derleme sayılarını seviyorum, ancak @David'in açıkladığı gibi olmasa da (major.minor.revision.HHMM). Ancak çalıştığım yerde, derleme sunucumuzun ürettiği sıralı bir sayı kullanıyoruz.

Jkohlhepp gibi, SubVersion'daki revizyon numarasını göstermek için sürümün üçüncü bölümünü ve sürekli entegrasyon sunucumuzdan (bizim için Jenkins) yapı numarasını göstermek için dördüncü sayısını kullanıyoruz. Bu bize birkaç avantaj sağlar - CI sunucumuz tarafından ayarlanan sürüm numarasının, aksi takdirde kaçırılması muhtemel olan manuel bir adımı kaldırması; Bir geliştiricinin geliştirme bilgisayarından arızalı bir sürüm çıkarmamış olduğunu kontrol etmek kolaydır (bu sayıların sıfır olmasına neden olur); ve bizi geri ondan oluşturulan kod hem yazılım herhangi bir parça kravat sağlar ve zaman zaman çok yararlı bulmak - sadece sürüm numarasına bakarak, inşa CI işi.

İstediğin her şey bu. Benim major.minor.build.revision için year.month.day.hhmm kullanın eğilimindedir. Dakikada bir taneden fazla üretiyorsam, bir sorun var. Sadece basit bir artış kullanabilirsiniz, ya da onlar için bazı ayrıntılı üreticiler gördüm. Ne olmasını istiyorsun? Yapmaları gereken şey, bu çıktının yaratılmasında kullanılan kaynağa ulaşmanızı sağlamaktır.

Son iki hane toplam yapı numarasıdır

1.01.2.1234

yapı numarası 2.1234, ancak çoğu kişi 1234'ü kullanacak, çünkü 2 bölüm sık sık değişmiyor.

Ekibimiz, üçüncü sayıyı (revizyon) Subversion deposundaki revizyon numarası olarak kullanır. Dördüncü sayıyı (yapı), derleme oluşturan TeamCity sürekli entegrasyon sunucumuzdan yapı numarası olarak kullanırız. TeamCity, derleme işlemi sırasında içinde # # bulunan yeni bir AssemblyInfo dosyası oluşturur.