Care este exact numărul de compilare din MAJOR.MINOR.BUILDNUMBER.REVISION

Nu l-am văzut niciodată scris în această formă. Acolo unde lucrez, folosim formularul MAJOR.MINOR.REVISION.BUILDNUMBER, unde:

• MAJOR este o versiune majoră (de obicei multe funcții noi sau modificări ale interfeței de utilizare sau OS care stă la baza)
• MINOR este o versiune minoră (poate unele funcții noi) pe o versiune majoră anterioară
• REVISION este de obicei o soluție pentru o versiune minoră anterioară (fără funcționalități noi)
• BUILDNUMBER este incrementat pentru fiecare cea mai recentă versiune a unei revizuiri.

De exemplu, o revizuire poate fi lansată în QA (controlul calității) și revine cu o problemă care necesită o schimbare. Bug-ul ar fi remediat și eliberat înapoi la QA cu același număr REVISION, dar un BUILDNUMBER incrementat.

Comentarii

• +1: That ‘ e cam așa cum l-am văzut și eu peste tot în altă parte. ‘ ‘ am văzut și mi-a plăcut cum unele companii folosesc doar o ștampilă DateTime pentru BUILDNUMBER.
• +1: ” MAJOR.MINOR.REVISION.BUILDNUMBER ” forma este de înțeles și are sens. Am văzut formularul BUILDNUMBER.REVISION pe site-ul MSDN (link actualizat în cauză) și m-a confundat total.
• Impar. M-aș aștepta ca ultima revizuire să aibă cel mai mult sens – este ‘ numărul care se va schimba (probabil) cel mai mult.
• @Izkata, de fapt versiunea numărul se schimbă cel mai mult, cel puțin modul în care îl folosim la contractul meu principal acum, care folosește un control strict al versiunilor, deoarece facem dispozitive medicale. O revizuire actualizată indică faptul că a existat o soluție la software-ul anterior, care trebuie testat de QA (Quality Assurance). Acesta este un departament complet separat, care efectuează teste extinse timp de trei zile (conform recomandărilor FDA). Dacă găsesc probleme, atunci ar putea fi necesare modificări suplimentare de cod care necesită o nouă versiune (recompilare și legătură) și apoi testare din nou, dar numărul revizuirii rămâne același.
• @tcrosley Cred că ‘ un caz de terminologie neclară. Mă gândeam la revizuiri în controlul versiunilor.

Toată confuzia provine din semantică diferită pe care MS o folosește pentru „Build number” și în special pentru „Revision”. Termenii înseamnă doar lucruri diferite.

Majoritatea oamenilor (inclusiv eu) folosesc o schemă de numerotare a versiunilor semantice în care obțineți doar un număr BUILD mai mare ori de câte ori trebuie să faceți o nouă construcție din orice motiv. Pentru noi, o remediere rapidă este considerată doar o altă modificare de cod, iar partea BUILD crește automat cu fiecare rulare CI. Modulele cu același MAJ.MIN.REV sunt considerate interschimbabile, iar BUILD vă spune care este cel mai recent.

Creșterea REVISION indică totuși o nouă ramură de lansare permanentă, de aceea o plasăm înainte de a CONSTRUI.Dezavantajul acestei abordări este că s-ar putea obține următoarea succesiune de evenimente:

• număr numărul 4711: Alice a adăugat caracteristica A
• CI produce versiunea 1.2.3.100
• numărul de validare 4712: caracteristica B modificată de
• numărul de validare 4713: caracteristica A fixată de Alice („remedierea rapidă”)
• CI produce versiunea 1.2.3.101

După cum puteți vedea, remedierea rapidă nu este singura modificare conținută în următoarea build, de asemenea, modificarea lui Bob devine parte a acestei build-uri. Dacă doriți să stabilizați ramura curentă, este posibil să întâmpinați probleme deoarece nu veți putea fi siguri dacă Bob a adăugat sau nu o grămadă de bug-uri.

MS folosește ambii termeni diferit. Numărul BUILD nu este incrementat automat, în schimb poate fi considerat un fel de ramură de lansare, pentru a îngheța codul utilizat pentru o anumită versiune a codului. REVIZIUNEA indică modificări „fierbinți” suplimentare aplicate acelei filiale BUILD. Prin urmare, secvența va fi după cum urmează:

• numărul de comitet 4711: Alice a adăugat caracteristica A la trunchi / master
• Carl creează ramura de construire 1.2.100
• CI produce versiunea 1.2.100.0
• numărul de validare 4712: caracteristica B modificată B în portbagaj / master
• numărul de validare 4713: caracteristica A fixată de Alice în ramura 1.2.100
• CI produce versiunea 1.2.100.1

Termenul REVISION se poate referi la

• un produs revizuire (așa o folosesc majoritatea oamenilor)
• o revizuire a unei anumite versiune zilnică (asta face MS)

Diferența cheie dintre cele două procese este, dacă doriți sau nu abilitatea de a aplica remedieri rapide la compilările CI și astfel, moment în care se realizează ramura. Acest aspect devine important atunci când doriți să puteți alege o anumită versiune în orice moment după ce toate testele au reușit și să promovați exact acea versiune la următoarea versiune oficială a produsului dvs.

În cazul nostru, instrumentul CI creează o etichetă de depozit, deci avem întotdeauna informațiile necesare gata de utilizare, atunci când este necesar. Cu SVN devine și mai simplu, deoarece etichetele și ramurile sunt implementate exact în același mod – o etichetă nu este altceva decât o ramură situată sub /tags.

Consultați de asemenea

Din secțiunea FAQ de la Strategia de ramificare TFS :

În ce ramură ar trebui să repar biletul P1 (remediere rapidă)?

• P1 ar trebui să fie fixat în ramura care este cea mai apropiată de baza de cod care rulează în Production. În acest caz, P1 trebuie fixat în ramura Prod. Prin aplicarea corecției în orice altă ramură și implementarea modificărilor producției, riscați să eliberați codul semifabricat sau netestat din iterațiile ulterioare.

• Acum puteți argumenta dacă este pentru a lucra direct împotriva ramurii Prod, gândiți-vă din nou, un P1 care necesită atenție imediată nu ar trebui să fie o problemă fundamentală în sistem. În cazul în care este o problemă fundamentală, ar trebui adăugată la restanța produsului, deoarece poate necesita analize și discuții suplimentare cu clientul.

O altă lectură bună este ghidul de ramificare TFS

Comentarii

• Acesta este un răspuns minunat! +1

Microsoft descrie scopul fiecărei componente a unui număr de versiune .NET în documentația MSDN pentru clasa Version. Iată porțiunea relevantă:

major.minor [.build [.revision]]

Componentele sunt utilizate prin convenție ca urmează:

Major: ansamblurile cu același nume, dar diferite versiuni majore nu sunt interschimbabile. Un număr de versiune mai mare ar putea indica o rescriere majoră a unui produs în care nu se poate presupune compatibilitatea cu versiunile anterioare.

Minor: dacă numele și numărul versiunii majore pe două ansambluri sunt aceleași, dar numărul versiunii minore este diferit, aceasta indică o îmbunătățire semnificativă cu intenția de compatibilitate inversă. Acest număr mai mare de versiune minoră ar putea indica o versiune punctuală a unui produs sau o nouă versiune complet compatibilă cu versiunile anterioare ale unui produs.

Build: O diferență în numărul de build reprezintă o recompilare a aceleiași surse. Numere diferite de compilare pot fi folosite atunci când procesorul, platforma sau compilatorul se schimbă.

Revizie: ansambluri cu același nume, versiuni majore și versiuni minore, dar versiuni diferite sunt destinate a fi complet interschimbabile. Un număr de revizuire mai mare ar putea fi utilizat într-o construcție care remediază o gaură de securitate într-un ansamblu lansat anterior.

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

Comentarii

• Mă descurcă de ce nimeni nu cunoaște acest standard, fiecare răspuns aici susține că construirea merge la final și nu ‘ nu înțeleg revizuirea este foarte simplă; înseamnă remedierea rapidă. Eliberați o versiune și apoi creați alte versiuni, dar când trebuie să reveniți și să remediați această versiune, actualizați versiunea pentru a afișa versiunea specială care a fost lansată a fost modificată pentru o nouă versiune
• +1 pentru un răspuns care are un număr de construcție justificat. Simpla creștere a numărului este destul de inutilă dacă revizuirea rămâne aceeași (cu excepția cazului în care aveți un sistem de construcție nebun care depinde de timp). Utilizarea numărului de compilare pentru a semnaliza ce compilator, platforme etc. este util.
• Build ca recompilation of the same source pare a fi un punct important care este ratat. Dacă ‘ este o modificare a codului (care nu necesită o creștere cu totul nouă majoră / minoră), atunci Revision trebuie, de asemenea, modificat.
• @PeterX La fel ca în cazul modificărilor specifice construcției la re-direcționare?
• ” O diferență în numărul de compilare reprezintă o recompilare a aceleiași surse ” pare să contrazică documentația. Odată ce ați făcut o revizuire, nu mai este aceeași sursă. A avea BUILD înainte de REVISION are sens numai dacă o revizuire este specifică unei construcții care reprezintă un procesor „, un procesor, o platformă sau o modificare a compilatorului „. Deci, cred că ceea ce majoritatea consideră o revizuire REVIZIUNE ar trebui să fie cu adevărat o lovitură MINORĂ atunci când se utilizează aceste descrieri. Deși documentele menționează utilizarea REVISION pentru remedierile rapide, dar cred că remedierile rapide se vor aplica tuturor versiunilor și, prin urmare, ar trebui să fie o reducere MINORĂ. Vreau doar o anumită consistență logică !!

Există cel puțin câteva lucruri diferite pe care le-aș putea imaginați-vă referința numărului de compilare:

1. Versiunea de control sursă care a fost lansată. De exemplu, dacă a existat o versiune a reviziei # 12345, acest lucru poate fi urmărit prin faptul că acesta este numărul de construcție și dacă este corecționat, acolo unde reviziile pot crește, deoarece nu este o funcționalitate nouă care ar crește versiunile majore sau minore iar numărul de compilare trebuie să fie amintit în cazul în care cineva dorește să ruleze din nou acea versiune.

2. Identificator server de integrare continuă. În acest caz, serverul CI poate numera fiecare versiune pe care o rulează și astfel numărul de compilare este ceea ce obține o versiune de succes, iar partea de revizuire nu este necesară în acest scenariu.

S-ar putea să existe și altele pe care nu le știu, dar acestea sunt cele mai mari pe care le știu când vine vorba de numere pe baze de coduri.

Comentarii

• +1 pentru # 1. Îmi place să folosesc revizuirea controlului sursă #, deoarece face mult mai ușor să căutați erori raportate împotriva acelei versiuni în controlul sursei.
• @MasonWheeler: funcționează excelent dacă sunteți pe SVN. Dar când ajungeți la dcvs devine veveriță y. Acesta ar fi un lucru care îmi lipsește cel mai mult la svn pe care îl voi adăuga ‘.

Un număr de compilare este de obicei incrementat la fiecare construcție, astfel încât este unic.

Din motive de simplitate, unii resetează numărul de construcție de fiecare dată când numerele MAJOR sau MINOR sunt blocate.

Majoritatea motoarelor de integrare continuă permit numere de construcție unice autogenerate.

Revizia poate fi utilizată pentru patch-uri din construiește. Să spunem că 2 echipe lucrează la un produs.

Echipa 1 este echipa principală de dezvoltare și produce o construcție nocturnă cu următoarea versiune schemă 1.0.X.0, unde X este incrementat. Acum sunt la versiunea 1.0.50.0 Echipa 2 ia o construcție din când în când. Să spunem că iau versiunea de săptămâna trecută, care este 1.0.43.0 și încep să o folosească. Echipa 1 avansează la 1.0.51.0 când echipa 2 găsește o problemă în 1.0.43.0.

Acum echipa 1 va luați acea versiune (43), remediați problema și furnizați echipei 2 versiunea 1.0.43.1. Soluția ar putea fi propagată și în versiunea principală, deci modificarea va apărea în versiunea 1.0.52.0.

Speranță acest lucru este clar și util.

* Revizuirea este utilă atunci când nu toți cei implicați în proiect folosesc aceeași versiune și trebuie să corelați versiuni specifice.

Permiteți-mi să spun cum îl văd și cum îl folosesc ….

ProgramName versiunea major.minor.build.revision

major: Pentru mine este proiectul curent la care lucrez. Numărul nu se va schimba până nu voi începe un nou proiect cu același nume de program. Aceasta înseamnă că voi scrie literalmente un nou program de același sex (exemplu: access v1 – access v-2 – access v-3 * tot același program, dar complet rescris).

minor: Aceasta înseamnă că sunt anunț funcționalitatea proiectului publicat curent.De exemplu, poate am adăugat posibilitatea de a imprima o chitanță sau am adăugat posibilitatea de a importa imagini. În principiu, vreau să adaug funcționalități suplimentare și să nu aștept următoarea versiune majoră pentru a o face.

build: Acest lucru îl folosesc pentru a indica modificări foarte mici în versiunea major.minor publicată. Aceasta ar putea fi o modificare a aspectului, schemei de culori etc.

revizuire: Aceasta o folosesc pentru a indica o remediere a erorilor în actualul major.minor.build publicat – Există ocazii în care nu progresez proiectul curent și apare o eroare. Această eroare trebuie reparată și publicată. Înseamnă doar că repar ceea ce am publicat deja pentru a funcționa corect. Aș folosi și acest lucru dacă lucrez la o nouă versiune, o nouă adăugare sau dacă aș începe o nouă versiune majoră. În mod evident, versiunea publicată trebuie reparată în timp ce așteptăm următoarea ediție majoră, minoră sau de construire.

Deci, în acest fel, un proiect finalizat sau blocat poate fi totuși remediat și utilizat până la următoarea ediție publicat.

Sper că acest lucru va oferi cuiva o mai bună înțelegere a modului în care ar funcționa (sau ar trebui) acest tip de versiune. Pentru mine este singura definiție și practică care are un sens real atunci când se utilizează acest tip de versionare.

„Am văzut doar un număr de compilare ca ultimul număr din ID-ul de lansare. Nu sunt sigur cum ați veni cu o revizuire a unui număr de compilare. Presupun că dacă ați schimbat unele dintre resursele neconstruite ( pictograme, script DB etc.), poate, dar majoritatea proiectelor la care am lucrat recent au și toate acele lucruri sub controlul versiunilor, astfel încât procesul de compilare le preia la realizarea programului de instalare / lansare. Îmi plac numerele de construcție marcate cu timp, deși nu chiar așa cum descrie @David (îmi place major.minor.revision.HHMM). Totuși, acolo unde lucrez, folosim doar un număr secvențial generat de serverul nostru de construire.

Este orice vrei să fie. Tind să folosesc year.month.day.hhmm pentru revizuirea mea majoră.minor.build.. Dacă produc mai mult de un minut, ceva nu este în regulă. poți folosi doar un increment simplu sau am văzut câteva generatoare elaborate pentru ei. Ce vrei tu să fie. Ce trebuie să facă este să o faci astfel încât să ajungi la sursa obișnuită creați acea ieșire, deci orice vă permite să faceți acest lucru.

Echipa noastră folosește al treilea număr (revizuire) ca numărul de revizuire din depozitul Subversion. Folosim al patrulea număr (build) ca număr de build de pe serverul nostru de integrare continuă TeamCity care creează de fapt build-ul. TeamCity creează un nou fișier AssemblyInfo cu numărul corect în acesta în timpul procesului de build. / p>

La fel ca jkohlhepp, folosim a treia parte a versiunii pentru a afișa numărul revizuirii în Subversiune și a patra pentru a afișa build number de pe serverul nostru de integrare continuă (Jenkins pentru noi). Acest lucru ne oferă câteva avantaje – dacă numărul de versiune setat de serverul nostru CI elimină un pas manual care altfel ar putea fi accidental ratat; este ușor să verificați dacă un dezvoltator nu a realizat o lansare obraznică de pe PC-ul de dezvoltare (ceea ce ar determina ca aceste numere să fie zero); și ne permite să legăm orice software înapoi atât la codul care a fost generat din cât și la jobul CI care l-a construit, doar privind numărul de versiune – pe care ocazional ni se pare foarte util.

Ultimele două cifre sunt numărul total al compilării

1.01.2.1234

numărul de compilare este 2.1234, însă majoritatea oamenilor vor folosi doar 1234, deoarece partea 2 nu se schimbă frecvent.

Comentarii

• OP solicită care este numărul de compilare, nu care este numărul de compilare din ID-ul de revizuire.