Qual è esattamente il numero di build in MAJOR.MINOR.BUILDNUMBER.REVISION

Non l'ho mai visto scritto in quella forma. Dove lavoro, stiamo usando il modulo MAJOR.MINOR.REVISION.BUILDNUMBER, dove MAJOR è una versione principale (di solito molte nuove funzionalità o modifiche all'interfaccia utente o al sistema operativo sottostante), MINOR è una versione secondaria (forse alcune nuove funzionalità) su una precedente versione principale, REVISION è in genere una correzione per una versione secondaria precedente (nessuna nuova funzionalità) e BUILDNUMBER viene incrementato per ogni ultima build di una revisione.

Ad esempio, una revisione può essere rilasciata al QA (controllo di qualità) e viene restituito un problema che richiede una modifica. Il bug sarebbe stato corretto e rilasciato nuovamente al QA con lo stesso numero di REVISIONE, ma un BUILDNUMBER incrementato.

Microsoft descrive lo scopo di ciascun componente di un numero di versione .NET nella documentazione MSDN per la classe Version . Ecco la parte pertinente:

major.minor[.build[.revision]]

The components are used by convention as follows:

Major: Assemblies with the same name but different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.

Minor: If the name and major version number on two assemblies are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.

Build: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.

Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.

link

L'intera confusione deriva dalla semantica diversa che MS usa per "Numero di build" e in particolare "Revision". I termini significano solo cose diverse.

La maggior parte delle persone (me compreso) usa uno schema di numerazione della versione semantica dove si ottiene un numero BUILD più alto ogni volta che si deve creare un nuovo build per qualunque ragione Per noi, un hotfix è considerato solo un altro cambiamento di codice e la parte BUILD aumenta automaticamente con ogni esecuzione di CI. I moduli con lo stesso MAJ.MIN.REV sono considerati intercambiabili e il BUILD ti dice quale è il più recente.

L'incremento della REVISIONE, tuttavia, indica un nuovo ramo di rilascio permanente, ecco perché lo posizioniamo prima di COSTRUIRE. Lo svantaggio di questo approccio è che potremmo ottenere la seguente sequenza di eventi:

• commit numero 4711: Alice ha aggiunto la funzione A
• CI produce build 1.2.3.100
• commit numero 4712: Bob ha modificato la funzione B
• commit numero 4713: Alice ha risolto la caratteristica A (la "correzione")
• CI produce build 1.2.3.101

Comepuoivedere,l'hotfixnonèl'unicamodificacontenutanellabuildsuccessiva,anchelamodificadiBobdiventapartediquellabuild.Sevuoistabilizzareilramoattuale,potrestiincorrereinproblemiperchénonpuoimaiesseresicurocheBobabbiaaggiuntoomenounsaccodibug.

MSutilizzaentrambiiterminiinmododiverso.IlnumeroBUILDnonvieneincrementatoautomaticamente,mapuòessereconsideratocomeunasortadiramodirilascio,perbloccareilcodiceutilizzatoperunaparticolareversionedelcodice.LaREVISIONEindicaulteriorimodifiche"hot" applicate a quel ramo BUILD. La sequenza sarebbe quindi la seguente:

• commit numero 4711: Alice ha aggiunto la funzione A a trunk / master
• Carl crea un ramo di build 1.2.100
• CI produce build 1.2.100.0
• commit numero 4712: Bob ha modificato la funzione B in trunk / master
• commit numero 4713: Alice ha risolto la caratteristica A nel ramo 1.2.100
• CI produce build 1.2.100.1

IltermineREVISIONEpuòriferirsia

• unaprodottorevisione(ècosìchelamaggiorpartedellagentelousa)
• unarevisionediunaparticolarebuildgiornaliera(questoèciòcheMSfa)

Ladifferenzachiavetraidueprocessiè,indipendentementedalfattosesidesideraomenolapossibilitàdiapplicareglihotfixallebuildCIequindi,aquelpuntodelprocesso,vienecreatoilramo.Questoaspettodiventaimportantequandosidesideraessereingradodiselezionareunaparticolarebuildinqualsiasimomentodopochetuttiitestsonoriuscitiepromuovereesattamentequellaversioneallasuccessivaversioneufficialedelprodotto.

NelnostrocasolostrumentoCIcreauntagdirepository,quindiabbiamosempreleinformazioninecessariepronteperl'uso,quandonecessario.ConSVNdiventaancorapiùsemplice,perchétageramivengonoimplementatiesattamentenellostessomodo:untagnonèaltrocheunramosituatosotto/tags.

Vedianche

DallasezioneDomandefrequentisu Strategia di diramazione TFS :

In what branch should I fix the P1 (hotfix) ticket?

• The P1 should be fixed in the branch that is closest to the code base running in Production. In this case the P1 should be fixed in the Prod branch. By applying the fix in any other branch and rolling out the changes to production you risk releasing semi-finished or untested code from the subsequent iterations.

• Now you may argue if it is safe to work directly against the Prod branch, think again, a P1 that requires immediate attention should not be a fundamental problem in the system. In case it is a fundamental problem it should be added to the Product backlog as it may require further analysis and discussion with the customer.

Un'altra buona lettura è la guida alla ramificazione di TFS

Ci sono almeno un paio di cose diverse che potrei immaginare il riferimento al numero di build:

1. Versione del controllo del codice sorgente rilasciata. Per esempio, se c'è stata una versione della revisione # 12345, questa può essere tracciata avendo il numero di build e se è patchato è dove possono andare le revisioni in quanto non è una nuova funzionalità che aumenterebbe le versioni maggiori o minori e il numero di build deve essere ricordato nel caso qualcuno voglia eseguire di nuovo quella build.

2. Identificatore server di integrazione continua. In questo caso, il server CI può numerare ogni build eseguita e quindi il numero di build è ciò che ottiene una build di successo e la parte di revisione non è necessaria in questo scenario.

Potrebbero essercene altri che non conosco, ma questi sono i più grandi che io conosca quando si tratta di numeri su basi di codice.

Generalmente un numero di build viene incrementato ad ogni build, quindi è univoco.

Per motivi di semplicità, alcuni ripristinano il numero di build ogni volta che i numeri MAJOR o MINOR sono urtati.

La maggior parte dei motori di integrazione continua consente numeri di build unici generati automaticamente.

La revisione può essere utilizzata per le patch delle build. Diciamo che 2 squadre lavorano su un prodotto.

Il Team 1 è il principale team di sviluppo e produce build notturne con il seguente schema di versione 1.0.X.0, in cui X viene incrementato. Ora sono a build 1.0.50.0 La squadra 2 sta prendendo una build di volta in volta. Diciamo che prendono la build della scorsa settimana che è 1.0.43.0 e inizia a usarla. La squadra 1 avanza fino a 1.0.51.0 quando la squadra 2 trova un problema in 1.0.43.0.

Ora il team 1 prenderà quella build (43), risolverà il problema e fornirà al team 2 la build 1.0.43.1. La correzione potrebbe anche essere propagata nella build principale, quindi la modifica verrà visualizzata in 1.0.52.0.

Spero che questo sia chiaro e utile.

* La revisione è utile quando non tutte le persone coinvolte nel progetto utilizzano la stessa build ed è necessario applicare patch a build specifiche.

Lasciami solo dire come lo vedo e usarlo ....

Versione ProgramName major.minor.build.revision

importante: Per me è il progetto attuale su cui sto lavorando. Il numero non cambierà fino a quando non avvierò un nuovo progetto con lo stesso nome del programma. Ciò significa che scriverò letteralmente un nuovo programma dello stesso genere (esempio: accesso v1 - accesso v-2 - accesso v-3 * allo stesso programma ma completamente riscritto).

minore: Ciò significa che aggiungo funzionalità al progetto pubblicato corrente. Ad esempio, forse ho aggiunto la possibilità di stampare una ricevuta o di aggiungere la possibilità di importare immagini. Fondamentalmente funzionalità aggiuntive che voglio aggiungere ora e non aspettare la prossima major release per farlo.

costruzione: Questo uso per indicare cambiamenti molto piccoli nella versione major.minor pubblicata. Questo potrebbe essere un cambiamento nel layout, nella combinazione di colori, ecc.

revisione: Questo uso per indicare una correzione di bug nel corrente major.minor.build pubblicato - Ci sono occasioni in cui non sto progredendo nel progetto corrente e si presenta un bug. Questo bug deve essere risolto e pubblicato. Significa solo che sto correggendo ciò che ho già pubblicato per funzionare correttamente. Lo userei anche se sto lavorando su una nuova build, una nuova aggiunta o se avvii una nuova versione principale. Ovviamente la versione pubblicata deve essere aggiornata mentre stiamo aspettando la prossima major, minor o build release.

Quindi in questo modo un progetto finito o in fase di stallo può ancora essere riparato e reso utilizzabile fino alla pubblicazione del prossimo rilascio.

Spero che questo dia a qualcuno una migliore comprensione di come questo (o di) dovrebbe funzionare. Per me è l'unica definizione e pratica che rende qualsiasi tipo di senso reale quando si utilizza questo tipo di controllo delle versioni.

Ho sempre visto solo un numero di build come ultimo numero nell'ID rilascio. Non sono sicuro di come sarebbe venuta fuori una revisione di un numero di build. Suppongo che se tu abbia modificato alcune delle risorse non costruite (icone, script DB, ecc.), Forse, ma la maggior parte dei progetti a cui ho lavorato di recente hanno tutte quelle cose anche sotto controllo di versione, quindi il processo di generazione le preleva quando rendendo l'installer / release. Mi piacciono i numeri di build con timestamp, anche se non proprio come descrive @David (mi piace major.minor.revision.HHMM). Tuttavia, dove lavoro, usiamo solo un numero sequenziale generato dal nostro server di generazione.

Come jkohlhepp, usiamo la terza parte della versione per mostrare il numero di revisione in SubVersion e la quarta per mostrare il numero di build dal nostro server di integrazione continua (Jenkins per noi). Questo ci dà molti vantaggi: il numero di versione impostato dal nostro server CI rimuove un passaggio manuale che altrimenti potrebbe essere ignorato per errore; è facile verificare che uno sviluppatore non abbia fatto una versione sfacciata dal proprio PC di sviluppo (il risultato sarebbe zero); e ci permette di legare qualsiasi pezzo di software sia al codice che è stato generato da e al lavoro di CI che lo ha generato, semplicemente guardando il numero di versione - che a volte troviamo molto utile.

È qualunque cosa tu voglia che sia. Tendo ad usare year.month.day.hhmm per il mio major.minor.build.revision. Se sto producendo più di un minuto, qualcosa non va. puoi semplicemente usare un semplice incremento o ho visto alcuni generatori elaborati per loro. Che cosa tu vuoi che sia. Quello che devono fare è farlo in modo che tu arrivi alla fonte usata per creare quell'output, quindi qualunque cosa ti permetta di farlo.

Le ultime due cifre sono il numero totale di build

1.01.2.1234

il numero di build è 2.1234, tuttavia la maggior parte delle persone utilizzerà solo il 1234 poiché la parte 2 non cambia frequentemente.

Il nostro team usa il terzo numero (revisione) come numero di revisione dal repository Subversion. Usiamo il quarto numero (build) come numero di build dal nostro server di integrazione continua TeamCity che crea effettivamente la build. TeamCity crea un nuovo file AssemblyInfo con i # # corretti in esso durante il processo di compilazione.