it-swarm.it

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

Quello che penso di Build Numbers è che ogni volta che viene creata una nuova build notturna, un nuovo BUILDNUMBER viene generato e assegnato a quella build. Quindi per la mia applicazione versione 7.0 le build notturne saranno 7.0.1, 7.0.2 e così via. È così? Allora a che serve una REVISIONE dopo il numero di build? Oppure la parte REVISIONE viene incrementata dopo ogni build notturno? Sono un po 'confuso qui ... ci riferiamo a ogni build notturno come a [~ # ~] build [~ # ~] ?

Il formato è menzionato qui: AssemblyVersion - MSDN

56
A9S6

Non l'ho mai visto scritto in quella forma. Dove lavoro, stiamo utilizzando il modulo MAJOR.MINOR.REVISION.BUILDNUMBER, in cui MAJOR è una versione principale (di solito molte nuove funzionalità o modifiche all'interfaccia utente o al sistema operativo sottostante), MINOR è una versione minore (forse alcune nuove funzionalità) su una versione principale precedente, 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 restituiscono un problema che richiede una modifica. Il bug sarebbe stato corretto e riportato al QA con lo stesso numero REVISION, ma con BUILDNUMBER incrementato.

58
tcrosley

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

La maggior parte delle persone (me compreso) usa un schema di numerazione della versione semantica in cui ottieni un numero BUILD più alto ogni volta che devi fare una nuova build per qualsiasi motivo. Per noi, un aggiornamento rapido è considerato solo un'altra modifica del codice e la parte BUILD aumenta automaticamente ad ogni esecuzione di CI. I moduli con lo stesso MAJ.MIN.REV sono considerati intercambiabili e BUILD ti dice quale è il più recente.

La REVISIONE in aumento, tuttavia, indica un nuovo ramo di rilascio permanente, ecco perché lo posizioniamo prima di BUILD. L'aspetto negativo di questo approccio è che potremmo ottenere la seguente sequenza di eventi:

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

major.minor.revision.build

Come puoi vedere, l'aggiornamento rapido non è l'unica modifica contenuta nella build successiva, ma anche la modifica di Bob diventa parte di quella build. Se si desidera stabilizzare il ramo corrente, è possibile che si verifichino problemi poiché non si può mai essere sicuri che Bob abbia aggiunto o meno un mucchio di bug.

MS utilizza entrambi i termini in modo diverso. Il numero BUILD non viene incrementato automaticamente, ma può essere considerato come una specie di ramo di rilascio, per bloccare il codice utilizzato per una particolare versione del codice. REVISION indica ulteriori modifiche "a caldo" applicate a quel ramo BUILD. La sequenza sarebbe quindi la seguente:

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

major.minor.build.revision

Il termine REVISIONE può riferirsi a

  • a product revision (that's how most people use it)
  • una revisione di un particolare build giornaliero (è quello che fa la SM)

La differenza chiave tra i due processi è, indipendentemente dal fatto che si desideri o meno la possibilità di applicare gli hotfix ai build degli elementi della configurazione e, quindi, a che punto del processo viene creato il ramo. Questo aspetto diventa importante quando vuoi essere in grado di scegliere una particolare build in qualsiasi momento dopo che tutti i test hanno avuto successo e promuovere esattamente quella versione alla prossima versione ufficiale del tuo prodotto.

Nel nostro caso lo strumento CI crea un tag repository, quindi abbiamo sempre le informazioni necessarie pronte per l'uso, quando necessario. Con SVN diventa ancora più semplice, perché i tag e i rami sono implementati esattamente allo stesso modo: un tag non è altro che un ramo situato sotto /tags.

Guarda anche

Dalla FAQ in strategia di ramificazione TFS :

In quale ramo devo riparare il ticket P1 (hotfix)?

  • Il P1 dovrebbe essere corretto nel ramo più vicino alla base di codice in esecuzione in Produzione. In questo caso il P1 dovrebbe essere riparato nel ramo Prod. Applicando la correzione in qualsiasi altra filiale e implementando le modifiche alla produzione, si rischia di rilasciare codice semilavorato o non testato dalle successive iterazioni.

  • Ora puoi discutere se è sicuro lavorare direttamente contro il ramo Prod, ripensaci, un P1 che richiede attenzione immediata non dovrebbe essere un problema fondamentale nel sistema. Nel caso in cui si tratti di un problema fondamentale, è necessario aggiungerlo all'arretrato di prodotto poiché potrebbe richiedere ulteriori analisi e discussioni con il cliente.

Un'altra buona lettura è la TFS branching guide

20
JensG

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]]

I componenti vengono utilizzati per convenzione come segue:

Maggiore: gli assiemi con lo stesso nome ma diverse versioni principali non sono intercambiabili. Un numero di versione superiore potrebbe indicare una riscrittura maggiore di un prodotto in cui non è possibile ipotizzare la compatibilità con le versioni precedenti.

Minore: se il nome e il numero di versione principale su due assiemi sono uguali, ma il numero di versione minore è diverso, ciò indica un miglioramento significativo con l'intenzione di compatibilità con le versioni precedenti. Questo numero di versione minore superiore potrebbe indicare una versione puntuale di un prodotto o una nuova versione di un prodotto completamente compatibile con le versioni precedenti.

Build: una differenza nel numero di build rappresenta una ricompilazione della stessa fonte. Numeri di build diversi potrebbero essere utilizzati quando il processore, la piattaforma o il compilatore cambiano.

Revisione: gli assiemi con lo stesso nome, i numeri di versione maggiore e minore ma revisioni diverse devono essere completamente intercambiabili. Un numero di revisione superiore potrebbe essere utilizzato in una build che risolve un problema di sicurezza in un assembly precedentemente rilasciato.

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

17
Cole Campbell

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

  1. Versione di controllo del codice sorgente rilasciata. Ad esempio, se è stata rilasciata una versione della revisione # 12345, è possibile tenere traccia di questo numero disponendo del numero di build e se è stato corretto il patch è il punto in cui le revisioni potrebbero aumentare in quanto non sono nuove funzionalità che aumenterebbero le versioni principali o secondarie e il numero di build deve essere ricordato nel caso in cui qualcuno voglia eseguire nuovamente quella build.

  2. Identificatore del server di integrazione continua. In questo caso, il server CI può numerare ogni build che esegue 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 quelli grandi che conosco quando si tratta di numeri su basi di codice.

4
JB King

Un numero di build viene generalmente incrementato ad ogni build, quindi è univoco.

Per semplicità, alcuni ripristinano il numero di build ogni volta che i numeri MAJOR o MINOR vengono eliminati.

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

3
user1249

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

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

Ora il team 1 prenderà quella build (43), risolverà il problema e fornirà alla 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 usano la stessa build e devi correggere patch per build specifiche.

2

Lasciami dire come lo vedo e lo uso ....

Versione ProgramName major.minor.build.revision

major: Per me è l'attuale progetto a cui sto lavorando. Il numero non cambierà finché non avvierò un nuovo progetto con lo stesso nome di programma. Questo significa che scriverò letteralmente un nuovo programma dello stesso genere (esempio: accesso v1 - accesso v-2 - accesso v-3 * tutto lo stesso programma ma completamente riscritto).

minore: questo significa che sto aggiungendo funzionalità al progetto pubblicato corrente. Ad esempio, forse ho aggiunto la possibilità di stampare una ricevuta o la possibilità di importare immagini. Fondamentalmente funzionalità aggiuntive che voglio aggiungere ora e non aspettare che la prossima versione principale lo faccia.

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

revisione: utilizzo questo per indicare una correzione di bug nell'attuale major.minor.build pubblicato - Ci sono occasioni in cui non sto avanzando il progetto corrente e si presenta un bug. Questo bug deve essere corretto e pubblicato. Significa solo che sto riparando ciò che ho già pubblicato per funzionare correttamente. Lo userei anche se sto lavorando su una nuova build, una nuova aggiunta o se ho avviato una nuova versione principale. La versione pubblicata deve ovviamente essere patchata mentre stiamo aspettando la prossima versione principale, minore o build.

Quindi in questo modo un progetto finito o bloccato può ancora essere risolto e reso utilizzabile fino alla pubblicazione della prossima versione.

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

2
Richard Rindom

Ho sempre visto un numero di build come l'ultimo numero nell'ID di rilascio. Non sono sicuro di come faresti con una revisione di un numero di build. Suppongo che se hai cambiato alcune delle risorse non costruite (icone, script DB, ecc.), Forse, ma la maggior parte dei progetti su cui ho lavorato di recente ha anche tutte quelle cose sotto il controllo della versione, quindi il processo di compilazione le raccoglie quando rendendo il programma di installazione/rilascio. Mi piacciono i numeri di build timestamp, anche se non esattamente come descrive @David (mi piace major.minor.revision.HHMM). Tuttavia, dove lavoro, usiamo solo un numero sequenziale generato dal nostro server di build.

1
TMN

Come jkohlhepp, utilizziamo 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 offre diversi vantaggi: avere il numero di versione impostato dal nostro server CI rimuove un passaggio manuale che altrimenti potrebbe essere perso accidentalmente; è facile verificare che uno sviluppatore non abbia rilasciato una versione sfacciata dal proprio PC di sviluppo (il che comporterebbe che questi numeri fossero zero); e ci consente di ricollegare qualsiasi parte del software sia al codice che è stato generato da e al lavoro CI che lo ha creato, semplicemente guardando il numero di versione - che a volte troviamo molto utile.

1
Jon Lawson

È qualunque cosa tu voglia che sia. Tendo a usare year.month.day.hhmm per la mia major.minor.build.revision. Se ne produco più di uno al minuto, qualcosa non va. puoi semplicemente usare un semplice incremento o ho visto alcuni generatori elaborati per loro. Cosa vuoi t vuoi che sia. Quello che devono fare è farlo in modo da arrivare alla fonte utilizzata per creare quell'output, quindi qualunque cosa ti permetta di farlo.

0
BlackICE

Le ultime due cifre rappresentano il numero totale di build

1.01.2.1234

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

0
lance lyons

Il nostro team utilizza 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 gli # giusti al suo interno durante il processo di compilazione.

0
RationalGeek