Quale schema di numerazione delle versioni mi consiglia?

StackOverflow https://stackoverflow.com/questions/121795

Domanda

La mia domanda è: quale schema di denominazione delle versioni dovrebbe essere usato per quale tipo di progetto.

Molto comune è major.minor.fix, ma anche questo può portare a 4 numeri (ad esempio Firefox 2.0.0.16). Alcuni hanno un modello che indica che numeri dispari indicano versioni per sviluppatori e numeri pari versioni stabili. E tutti i tipi di aggiunte possono entrare nel mix, come -dev3, -rc1, SP2 ecc.

Esistono motivi per preferire uno schema rispetto a un altro e dovrebbero diversi tipi di progetti (ad esempio Open Source vs. Closed Source) avere schemi di denominazione delle versioni diversi?

È stato utile?

Soluzione

Ci sono due buone risposte per questo (oltre a molte preferenze personali, vedi il commento di Gizmo sulle guerre di religione)

Per le applicazioni pubbliche , Major.Minor.Revision.Build standard funziona meglio IMO: gli utenti pubblici possono facilmente dire quale versione del programma hanno e, in una certa misura, fino a che punto la loro versione è.

Per le applicazioni in casa , dove gli utenti non hanno mai richiesto l'applicazione, la distribuzione è gestita dall'IT e gli utenti chiameranno l'help desk, ho trovato Year.Month.Day.Build per lavorare meglio in molte situazioni. Questo numero di versione può quindi essere decodificato per fornire informazioni più utili all'help desk rispetto allo schema del numero di versione pubblico.

Comunque alla fine farei una raccomandazione sopra ogni altra cosa - uso un sistema che puoi mantenere coerente . Se esiste un sistema che puoi configurare / creare script per il tuo compilatore da utilizzare automaticamente ogni volta, usalo .

La cosa peggiore che può accadere è il rilascio di file binari con lo stesso numero di versione dei precedenti: di recente ho avuto a che fare con rapporti sugli errori di rete automatizzati (qualcuno elude l'applicazione) e sono giunto alla conclusione che l'Anno. .Day.I numeri di versione di build mostrati nei dump principali non erano nemmeno aggiornati in remoto con l'applicazione stessa (l'applicazione stessa utilizzava una schermata iniziale con i numeri reali - che ovviamente non erano disegnati dal binario come si potrebbe supporre). Il risultato è che non ho modo di sapere se i crash dump provengono da un binario di 2 anni (cosa indica il numero di versione) o da un binario di 2 mesi, e quindi non c'è modo di ottenere il giusto codice sorgente (nessun controllo del codice sorgente! )

Altri suggerimenti

Ecco cosa utilizziamo nella nostra azienda: Maggiore . Minore . Versione patch . Numero build .

La modifica Maggiore comporta un ciclo di rilascio completo, incluso il coinvolgimento nel marketing, ecc. Questo numero è controllato da forze al di fuori di R & D (ad esempio, in uno dei posti in cui ho lavorato, il Marketing ha deciso che la nostra prossima versione sarebbe stata "11" - per abbinare un concorrente. All'epoca eravamo alla versione 2 :) ).

Minore viene modificato quando al prodotto viene aggiunta una nuova funzionalità o una modifica sostanziale del comportamento.

Versione patch aumenta di uno ogni volta che una patch viene aggiunta ufficialmente alla versione, di solito includendo solo correzioni di bug.

Versione build viene utilizzato quando viene rilasciata una versione speciale per un cliente, in genere con una correzione di bug specifica per lui. Di solito tale correzione verrà implementata per la prossima patch o versione secondaria (e la gestione del prodotto di solito segnala il bug come "sarà rilasciato per la patch 3" nel nostro sistema di tracciamento).

Sono un grande fan di Versioning semantico

Come molti altri hanno commentato, questo utilizza il formato X.Y.Z e fornisce buone ragioni sul perché.

Il nostro dipartimento R & amp; D utilizza 1.0.0.0.0.000: MAJOR.minor.patch.audience.critical_situation.build

Per favore, per favore , non farlo.

Questo tipo di domanda riguarda più la guerra religiosa che aspetti oggettivi. Ci sono sempre tonnellate di pro e contro contro uno schema di numerazione o un altro. Tutto ciò che le persone potrebbero (o dovrebbero) darti è lo schema che hanno usato e perché lo scelgono.

Da parte mia, uso uno schema X.Y.Z tutti sono numeri in cui:

  • X indica una modifica nell'API pubblica che introduce incompatibilità con le versioni precedenti
  • Y indica un'aggiunta di alcune funzioni
  • Z indica una correzione (o correzione di un bug, o modifica della struttura interna senza impatto sulla funzionalità)

Alla fine, utilizzo " Beta N " suffisso se desidero ricevere feedback dagli utenti prima che venga effettuata una versione ufficiale. No " RC " suffisso poiché nessuno è perfetto e ci saranno sempre dei bug ;-)

Preferisco personalmente MAJOR.MINOR.BUGFIX-SUFFIX dove SUFFIX è dev per le versioni di sviluppo (checkout di controllo versione), rc1 / rc2 per i candidati al rilascio e nessun suffisso per le versioni del rilascio.

Se hai suffissi per i checkout di sviluppo, magari anche con il numero di revisione, non è necessario renderli pari / dispari per tenerli separati.

Preferiamo lo schema major . minor . milestone . revisione - build , dove:

  • major : incrementi di modifiche architettoniche significative o importanti progressi nelle capacità.
  • minor : piccole modifiche e nuove funzionalità che non richiedono modifiche architettoniche.
  • milestone : indica la stabilità e la maturità del codice:
    • 0 per sviluppo / pre-alfa
    • 1 per alpha
    • 2 per beta
    • 3 per rilascio candidato (RC)
    • 4 per il rilascio finale / di produzione
  • revisione : indica il numero di release, patch o bugfix.
  • build : riferimenti univoci a build o versioni specifiche di un'applicazione. Il numero di build è un numero intero sequenziale, generalmente incrementato ad ogni build.

Esempi:

  • 1.4.2.0-798 : prima versione beta della versione 1.4 , creata dal numero di build 798 .
  • 1.8.3.4-970 : 1.8-RC4 , creato dal numero di build 970 .
  • 1.9.4.0-986 : prima versione di produzione della versione 1.9 , creata dal numero di build 986 .
  • 1.9.4.2-990 : seconda versione del bugfix della versione 1.9 , creata dal numero di build 990 .

Poiché le versioni di prodcution hanno sempre 4 nella loro terza cifra della stringa di versione, la cifra può essere rimossa per le versioni di produzione.

Nel caso di una libreria, il numero di versione indica il livello di compatibilità tra due versioni e quindi la difficoltà di un aggiornamento.

Una versione con correzione di bug deve preservare la compatibilità binaria, di origine e di serializzazione.

Le versioni minori significano cose diverse per progetti diversi, ma di solito non hanno bisogno di preservare la compatibilità dei sorgenti.

I numeri di versione principali possono interrompere tutte e tre le forme.

Ho scritto di più sulla logica qui .

Con le pratiche di sviluppo del software Agile e le applicazioni SaaS, l'idea di una versione Major vs. a Minor è scomparsa - le versioni escono molto frequentemente su base regolare - quindi uno schema di numerazione delle versioni che si basa su questa distinzione non è più utile per me.

La mia azienda utilizza uno schema di numerazione che prende le ultime 2 cifre dell'anno in cui la versione è iniziata seguita dal numero di versione entro quell'anno.

Quindi, la quarta versione iniziata nel 2012 sarebbe la 12.4.

Puoi includere una correzione di bug " il numero di versione successivo, se necessario, ma idealmente stai rilasciando abbastanza frequentemente che questi non sono spesso necessari, quindi "12.4.2".

Questo è uno schema molto semplice e non ci ha dato nessuno dei problemi di altri schemi di numerazione delle versioni che ho usato prima.

La differenza tra una politica di numero di versione di versione chiusa e open source può anche provenire da un aspetto commerciale , quando la versione principale può riflettere l'anno della versione, ad esempio.

Ciò che eravamo soliti fare qui è major.minor.platform.fix .

major : aumentiamo questo numero quando i file salvati da questa build non sono più compatibili con la build precedente.
Esempio : i file salvati nella versione 3.0.0.0 non saranno compatibili con la versione 2.5.0.0.

minore : aumentiamo questo numero quando è stata aggiunta una nuova funzione. Questa funzione dovrebbe essere visualizzata dall'utente. Non è una funzione nascosta per lo sviluppatore. Questo numero viene reimpostato su 0 quando viene incrementato major.

piattaforma : questa è la piattaforma che utilizziamo per lo sviluppo.
Esempio : 1 sta per .net framework versione 3.5.

correzione : aumentiamo questo numero quando in questa nuova versione sono incluse solo correzioni di bug. Questo numero viene reimpostato su 0 quando viene incrementato maggiore o minore.

Semplicemente 

Major.Minor.Revision.Build
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top