Ciò che ogni mezzo di cifre di versione del software (1.7.1.0, per esempio)?

Question

Che cosa potrebbe significare in ogni cifra versione del software? (Per esempio, 1.7.1.0) Come si fa a far di conto le vostre versioni?

Grazie.

Answer 1

Si differenzia da fornitore a fornitore veramente. Più comunemente, sono (in ordine):

• Maggiore numero di release
• Minor numero di release
• Manutenzione numero di release (correzioni solo)
• Se usato affatto: numero di build (o controllo del codice sorgente numero di revisione)

1.7.1.0 questo sarebbe la prima release di manutenzione per la versione 1.7 del prodotto.

Anche definire quale sia la differenza tra un maggiore e minore rilascio è, è difficile. Le principali versioni includono normalmente nuove importanti funzionalità. O il venditore vuole solo ancora una volta la gente a pagare per il prodotto. minor release possono includere correzioni e nuove funzionalità, ma di solito rottura niente terra.

Alcune aziende utilizzano il bit di minor release di distinguere tra alfa / versioni beta e release finali. I numeri dispari essendo pre-release e numeri pur essendo finali. 1.7 sarebbe una beta di un imminente rilascio 1.8. Questa abitudine sta diventando sempre meno comune, anche se.

numeri di build incrementano ad ogni rilascio, non importa quanto minore i cambiamenti potrebbero essere. Esso viene incrementato automaticamente dal processo di generazione, ogni volta che viene eseguito. Molte generazioni sono non vedi mai rilasciato pubblicamente, ma possono aiutare nella gestione del ciclo di vita del software, rendendo più facile per QA per identificare in modo univoco una versione del software.

Answer 2

Normalmente questi sono <Major.Minor.Revision.Build>.

Dove:

• Major è un importante aggiornamento per il software
• Minor è un piccolo aggiornamento al software
• Revisione è qualsiasi modifica apportata (correzioni di bug, piccoli aggiornamenti)
• numero di build (normalmente un incremento automatico se utilizzato)

Nel tuo esempio (1.7.1.0):

• Maggiore versione 1
• aveva 7 aggiornamenti minori
• Prima revisione / bugfix
• Nessun numero di build

Answer 3

Ogni progetti sceglie il proprio convenzione. Come altri hanno già fuori a punta, una convenzione comune è "Major.Minor.Revision.Build"

Un paio di miei preferiti sono:

versioni

?? Ubuntu sono "Year.Month". Ad esempio, 10.04 è stato rilasciato nel mese di aprile del 2010.

versioni

?? TeX teoricamente solo Bux-fix per sempre , così le loro versioni sono asintoticamente pi (ad es 3.1415926)

Answer 4

Dipende. Ecco alcune informazioni su numeri di versione di Microsoft http://en.wikipedia.org/wiki/Microsoft_Version_Number

Abbiamo usato l'ultima cifra, come numeri di build per le nostre applicazioni.

Answer 5

Un altro metodo è ampiamente usato avente un numero di generazione incrementale. Senza alcuna correlazione con la cosiddetta "versione".

"versione" è più interessante per i consumatori che vogliono sapere che questo è un nuovo prodotto, quindi basta dare ogni rilascio di un nome.

Ma per usi interni e una facile consultazione del prodotto e la sua versione testata \ origine controllata, un numero di build semplice l'incremento potrebbe essere più conveniente.

Answer 6

Ecco come IBM definisce questi per software WebSphere , tra cui una spiegazione di quali criteri delineano ogni livello.