Mi chiedo come decidi il numero di versione delle tue app, annoti davvero tutte le modifiche apportate (per un registro delle modifiche)? Quindi come deciderà come incrementare il numero di versione. per esempio. +0.0.1 per ogni correzione di bug o qualcosa del genere, +0.1 per ogni nuova release di funzionalità? o forse impacchetta molte modifiche in +0.1 del tuo numero di versione?
Major.Minor.Revision
Sebbene questo sia cambiato nel corso degli anni (ho lavorato su diversi progetti che utilizzavano diversi schemi di versioning), è sempre stato qualcosa del genere:
la versione principale, la versione secondaria e la versione di aggiornamento
X.Y.Z.WWWW
X: major release con nuove funzionalità identificabili
Y: versione minore con miglioramenti delle funzionalità esistenti
Z: update release (distributed) contenente correzioni di bug ma nessuna nuova funzionalità
W: build di codice - interno ai programmatori
Questi numeri di versione del programma non corrispondevano necessariamente ai numeri utilizzati dal marketing. Quello che voglio dire? Ad esempio, Word 2000 (comunicato al pubblico) è in realtà Word 9.0.1.3821 (interno al team del prodotto). Il marketing del prodotto possiede il nome distribuito; Lo sviluppo possiede il controllo delle versioni e il nome del codice del progetto.
I piani di numerazione sono in gran parte irrilevanti per i clienti; il versioning è solo per tenere traccia di ciò che viene spedito al cliente. Ci sono molti sviluppatori di software che pensano che gli schemi di numerazione siano un aspetto di marketing non importante del prodotto. Le persone e i clienti di marketing generalmente non si preoccupano (o non dovrebbero) dei numeri di versione.
Dopo aver letto un sacco di articoli / QA / FAQ / libri, ho iniziato a pensare che [MAJOR]. [MINOR]. [REV] è lo schema di versioning più utile a descrivere la compatibilità tra la versione del progetto (schema di versioning per lo sviluppatore, non per il marketing).
Le modificheMAJOR sono incompatibili con le versioni precedenti e richiedono modifiche nome del progetto, percorso dei file, GUID, ecc.
Le modificheMINOR sono compatibili con le versioni precedenti. Contrassegna l'introduzione di nuovi caratteristiche.
REV per la sicurezza / correzioni di errori. Compatibile con le versioni precedenti e successive.
Questo schema di versioning è ispirato alla semantica della versione di libtool e dagli articoli:
NOTA: ti consiglio inoltre di fornire build / date / custom / quality come informazioni aggiuntive (compilazione numero, data di costruzione, nome del cliente, qualità di rilascio):
Ciao app v2.6.34 per Banca nazionale , 2011-05-03 , beta , build < strong> 23545
Ma questa informazione è non informazioni sulla versione !!
UPDATE per coloro che si riempiono da hipster - link - come in libtool docs ma brillano come Web 2.0.
Apportare questo cambiamento a mano farà sì che i clienti abbiano versioni diverse delle DLL con lo stesso numero di versione. l'unico modo sicuro che conosco è usare il server Build per farlo automaticamente. Il build server aggiungerà 0.0.1 ogni volta che viene creato il codice.
Per quanto mi riguarda, le modifiche 0.1 e 1. si verificano quando si creano rami di rilascio, mantenendo lo sviluppo del tronco come 0.0.0.x
Generalmente è un numero Major.minor.revision. Il numero maggiore e minore è scelto dai tipi di marketing per riflettere la suggestione o la mancanza di suggestione nella nuova versione. Il numero di revisione è dettato dal sistema di controllo della versione.
Leggi altre domande sui tag versioning