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

Non lho mai vista scritta in quella forma. Dove lavoro, utilizziamo il modulo MAJOR.MINOR.REVISION.BUILDNUMBER, dove:

• MAJOR è una versione principale (di solito molte nuove funzionalità o modifiche allinterfaccia utente o sistema operativo sottostante)
• MINOR è una versione minore (forse alcune nuove funzionalità) su una versione principale precedente
• REVISIONE è solitamente una correzione per una versione minore precedente (nessuna nuova funzionalità)
• BUILDNUMBER viene incrementato per ogni ultima build di una revisione.

Ad esempio, una revisione può essere rilasciata al QA (controllo di qualità) e si ripresenta un problema che richiede un cambiamento. Il bug verrebbe corretto e rilasciato al QA con lo stesso numero di REVISIONE, ma con un BUILDNUMBER incrementato.

Commenti

• +1: That ‘ è praticamente il modo in cui ‘ lho visto anche altrove. ‘ ho visto e apprezzato il modo in cui alcune aziende utilizzano semplicemente un timbro DateTime per BUILDNUMBER.
• +1: il ” MAJOR.MINOR.REVISION.BUILDNUMBER ” è comprensibile e ha senso. Ho visto il modulo BUILDNUMBER.REVISION sul sito MSDN (collegamento aggiornato in questione) e mi ha completamente confuso.
• Strano. Mi aspetto che la revisione sia lultima per avere più senso: ‘ è il numero che (probabilmente) cambierà di più.
• @Izkata, in realtà la build il numero cambia di più, almeno il modo in cui lo usiamo nel mio contratto principale in questo momento che utilizza un rigoroso controllo della versione perché stiamo producendo dispositivi medici. Una revisione aggiornata indica che è stata apportata una correzione al software precedente, che deve essere testato da QA (Quality Assurance). Questo è un dipartimento completamente separato che esegue test approfonditi per tre giorni (secondo le linee guida della FDA). Se rilevano problemi, potrebbero essere necessarie ulteriori modifiche al codice richiedendo una nuova build (ricompilazione e collegamento) e quindi ripetere il test, ma il numero di revisione rimane lo stesso.
• @tcrosley Immagino che ‘ è un caso di terminologia poco chiara. Stavo pensando alle revisioni nel controllo della versione.

Lintera confusione deriva dal semantica che MS utilizza per “Numero build” e soprattutto “Revisione”. I termini significano solo cose diverse.

La maggior parte delle persone (me compreso) utilizza uno schema di numerazione delle versioni semantico in cui ottieni solo un numero BUILD più alto ogni volta che devi creare una nuova build per qualsiasi motivo. Per noi, un hotfix è considerato solo unaltra modifica al codice e la parte BUILD aumenta automaticamente a ogni esecuzione dellelemento della configurazione. I moduli con lo stesso MAJ.MIN.REV sono considerati intercambiabili e BUILD ti dice qual è il più recente.

Incrementare REVISION, tuttavia, indica un nuovo ramo di rilascio permanente, ecco perché lo mettiamo prima di BUILD.Lo svantaggio di questo approccio è che potremmo ottenere la seguente sequenza di eventi:

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

Come puoi vedere, lhotfix non è lunica modifica contenuta nel prossimo build, anche le modifiche di Bob diventano parte di quella build. Se vuoi stabilizzare il ramo corrente, potresti incorrere in problemi poiché non puoi mai essere sicuro 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 una sorta di ramo di rilascio, per congelare il codice utilizzato per una particolare versione del codice. La REVISIONE indica ulteriori modifiche “a caldo” applicate a quel ramo BUILD. La sequenza sarebbe quindi la seguente:

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

Il termine REVISIONE può riferirsi a

• un prodotto revisione (è così che la maggior parte delle persone la usa)
• una revisione di una particolare build giornaliera (questo è ciò che fa MS)

La differenza fondamentale tra i due processi è se si desidera o meno la possibilità di applicare hotfix alle build CI e quindi, a quel 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 sono andati a buon fine e promuovere esattamente quella versione alla prossima versione ufficiale del tuo prodotto.

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

Vedi anche

Dalla sezione delle domande frequenti su Strategia di diramazione TFS :

In quale ramo dovrei correggere 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 fissato nel ramo Prod. Applicando la correzione in qualsiasi altro ramo e implementando le modifiche alla produzione, rischi di rilasciare codice semilavorato o non testato dalle iterazioni successive.

• Ora puoi discutere se è sicuro di lavorare direttamente contro il ramo Prod, ripensateci, un P1 che richiede unattenzione immediata non dovrebbe essere un problema fondamentale nel sistema. Nel caso si tratti di un problema fondamentale, dovrebbe essere aggiunto al Product backlog in quanto potrebbe richiedere ulteriori analisi e discussioni con il cliente.

Unaltra buona lettura è la TFS branching guide

Comments

• Questa è unottima risposta! +1

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

major.minor [.build [.revision]]

I componenti sono usati per convenzione come segue:

Maggiore: gli assembly con lo stesso nome ma versioni principali diverse non sono intercambiabili. Un numero di versione più alto potrebbe indicare una riscrittura principale di un prodotto in cui non è possibile presumere la compatibilità con le versioni precedenti.

Minore: se il nome e il numero di versione principale su due assembly sono gli stessi, ma il numero di versione minore è diverso, ciò indica un miglioramento significativo con lintenzione di compatibilità con le versioni precedenti. Questo numero di versione minore più alto potrebbe indicare una versione ridotta di un prodotto o una nuova versione completamente compatibile con le versioni precedenti di un prodotto.

Build: una differenza nel numero di build rappresenta una ricompilazione della stessa fonte. Quando il processore, la piattaforma o il compilatore vengono modificati, potrebbero essere utilizzati numeri di build diversi.

Revisione: gli assembly con lo stesso nome, numeri di versione principale e secondaria ma diverse revisioni sono intese per essere completamente intercambiabili. Un numero di revisione più alto potrebbe essere utilizzato in una build che risolve un problema di sicurezza in un assembly rilasciato in precedenza.

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

Commenti

• Mi sconcerta perché nessuno conosce questo standard, ogni risposta qui afferma che la build va alla fine e non ‘ t capire che la revisione è molto semplice; significa hotfix. Rilasci una build e quindi crei ulteriori build, ma quando devi tornare indietro e correggere quella versione, aggiorni la revisione per mostrare che la build particolare che è stata rilasciata è stata modificata per una nuova versione
• +1 per una risposta con un numero di build giustificabile. Il semplice incremento del numero è piuttosto inutile se la revisione rimane la stessa (a meno che tu non abbia un sistema di compilazione folle che dipende dal tempo). Utilizzo del numero di build per segnalare quale compilatore, piattaforme e così via è utile.
• Build come recompilation of the same source sembra essere un punto importante che è mancato. Se ‘ è una modifica del codice (che ‘ t richiede un nuovo aumento Maggiore / Minore), il Revision deve essere modificato.
• @PeterX Come nel caso di modifiche specifiche della build durante il re-targeting?
• ” Una differenza nel numero di build rappresenta una ricompilazione della stessa fonte ” sembra contraddire la documentazione. Una volta effettuata una revisione, non è più la stessa fonte. Avere BUILD prima di REVISION ha senso solo se una revisione è specifica per una build che rappresenta un ” modifica di processore, piattaforma o compilatore “. Quindi immagino che quello che la maggior parte vede come un urto di REVISIONE dovrebbe davvero essere un urto MINORE quando si usano queste descrizioni. Sebbene i documenti menzionino luso di REVISIONE per gli hotfix, lId presume che gli hotfix si applicheranno a tutte le build e dovrebbero quindi essere un urto MINORE. Voglio solo un po di coerenza logica !!

Ci sono almeno un paio di cose diverse che potrei immagina il numero di build che fa riferimento:

1. Versione del controllo del codice sorgente che è stata rilasciata. Ad esempio, se ci fosse una versione della revisione # 12345, questo potrebbe essere tracciato facendo in modo che sia il numero di build e se è patchato è qui che 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 desideri eseguire di nuovo 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 i più grandi che conosco quando si tratta di numeri su basi di codice.

Commenti

• +1 per # 1. Mi piace usare il revisione del controllo del codice sorgente #, perché rende molto più semplice cercare i bug segnalati rispetto a quella versione nel controllo del codice sorgente.
• @MasonWheeler: funziona benissimo se sei su SVN. Ma quando arrivi a dcvs fallo ottiene lo scoiattolo y. Questa sarebbe una cosa che mi manca di più di svn I ‘ ll add.

Un numero di build viene solitamente incrementato ad ogni build in modo che sia unico.

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

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

La revisione può essere utilizzata per le patch del costruisce. Diciamo che 2 team 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, dove X viene incrementato. Ora sono alla build 1.0.50.0 Il team 2 sta prendendo una build di tanto in tanto. Supponiamo che prendano la build della scorsa settimana che è 1.0.43.0 e inizino a usarla. La squadra 1 passa alla 1.0.51.0 quando la squadra 2 trova un problema nella 1.0.43.0.

Ora la squadra 1 lo farà prendi quella build (43), risolvi il problema e fornisci al team 2 la build 1.0.43.1. La correzione potrebbe essere propagata anche nella build principale, quindi la modifica apparirà nella 1.0.52.0.

Spero questo è chiaro e utile.

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

Vorrei solo dire come lo vedo e come lo uso ….

ProgramName versione major.minor.build.revision

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

minor: questo significa che sono ad funzionalità ding al progetto pubblicato corrente.Ad esempio forse ho aggiunto la possibilità di stampare una ricevuta o ho aggiunto la possibilità di importare immagini. Fondamentalmente funzionalità aggiuntive che voglio aggiungere ora e non aspettare la prossima versione principale per farlo.

build: questo lo uso per indicare modifiche molto piccole nella versione major.minor pubblicata. Potrebbe trattarsi di un cambiamento nel layout, nello schema dei colori, ecc.

Revisione: lo uso per indicare una correzione di bug nellattuale major.minor.build pubblicato – Ci sono occasioni in cui non sto procedendo progetto in corso e sorge un bug. Questo bug deve essere corretto e pubblicato. Significa solo che sto sistemando quello che ho già pubblicato per funzionare correttamente. Lo userei anche se sto lavorando a una nuova build, una nuova aggiunta o se ho iniziato una nuova versione principale. La versione pubblicata ovviamente deve essere patchata mentre siamo in attesa del prossimo rilascio principale, secondario o build.

Quindi in questo modo un progetto finito o bloccato può ancora essere riparato e reso utilizzabile fino al rilascio successivo pubblicato.

Spero che questo dia a qualcuno una migliore comprensione di come questo tipo di controllo delle versioni potrebbe (o dovrebbe) funzionare. Per me è lunica definizione e pratica che ha senso quando si utilizza questo tipo di controllo delle versioni.

Ho visto solo un numero di build come ultimo numero nellID della versione. Non sono sicuro di come avresti trovato una revisione per un numero di build. Suppongo che se avessi modificato alcune delle risorse non costruite ( icone, script DB, ecc.), forse, ma la maggior parte dei progetti su cui ho lavorato di recente hanno anche tutte queste cose sotto il controllo della versione, quindi il processo di compilazione le raccoglie quando si effettua il programma di installazione / rilascio. Mi piacciono i numeri di build con data e ora, 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 compilazione.

È quello che vuoi essere. 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 tu vuoi che sia. Quello che devono fare è farlo in modo da arrivare alla fonte abituata creare quelloutput, quindi qualunque cosa ti permetta di farlo.

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 effettivamente crea la build. TeamCity crea un nuovo file AssemblyInfo con il giusto # in esso durante il processo di build.

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 offre diversi vantaggi: avere il numero di versione impostato dal nostro server CI rimuove un passaggio manuale che altrimenti potrebbe essere accidentalmente perse; è facile controllare che uno sviluppatore non abbia fatto un rilascio sfacciato dal proprio PC di sviluppo (il che porterebbe a zero questi numeri); e ci permette di ricollegare qualsiasi pezzo di software sia al codice che è stato generato da e il lavoro CI che lo ha costruito, semplicemente guardando il numero di versione – che a volte troviamo molto utile.

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 1234 poiché la parte 2 non cambia frequentemente.

Commenti

• LOP chiede qual è il numero di build, non quale è il numero di build nellID di revisione.