Molti aggiornamenti software seguono lo schema dalla v0.1 alla v0.2 a v2.6.5.6 . Cosa significano veramente questi "aggiornamenti" sul software? C'è uno standard del settore sempre seguito o i programmatori continuano a sollevare l'aggiornamento # o aggiungendo più decimali?
Come ha detto Shaun, non c'è davvero uno standard. Alcune aziende hanno migliori pratiche di versioning rispetto ad altre (mi sono occupato di venditori che saltano i numeri di versione principali, e altri che sono bloccati sulla stessa x.y diverse versioni successive).
Detto questo, l'inventore di Gravatars e cofondatore di GitHub ( Tom Preston-Werner ) ha creato un documento per 'Semantic Versioning " che vale più di una lettura.
Ecco l'eccezione dell'intro:
As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.
I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.
Con 4 cifre solitamente è MajorV.MinorV.PatchNum.BuildNum, almeno dove lavoro.
Personalmente preferisco lo schema di versioni di Ubuntu - rende la vita molto più semplice.
La versione breve è che non esiste uno standard e le aziende fanno ciò che vogliono. Essenzialmente, più numeri hai, più piccola è la quantità di modifiche rappresentate da ciascun numero. Comunemente, vedrete almeno la versione x.y, dove x una modifica in x indica le versioni principali (miglioramenti principali / implementazioni delle funzioni) e y le versioni minori (modifiche significative o correzioni di errori). Più decimali dopo questi due possono significare cose diverse internamente a un'azienda, anche se spesso ruotano attorno a piccole build o patch che rappresentano correzioni più rapide e più piccole.
Wikipedia ha un articolo che tratta questo in maggior dettaglio.
Lo scopo dei numeri di versione è di fornire un riferimento per le segnalazioni di problemi. L'unico requisito è che ogni versione abbia un numero di versione univoco. Alcuni numeri sono guidati dal marketing: numeri interi più grandi sono più facili da vendere e numeri di potere come 10 (numero romano X) sono davvero accattivanti. Alcune persone usano alcune varianti di versioning semantico:
MAJOR.MINOR.MICRO.BUILD
Molti gruppi rilasciano il numero BUILD nelle loro versioni. Di solito è utile solo tra test e gruppi di sviluppo.
Alcuni gruppi aggiungono semantica aggiuntiva, come gli incrementi MINORI con numero dispari per le build sperimentali e gli incrementi MINORI pari numerati sono per le versioni di produzione ( Il kernel Linux utilizza questo approccio).
La linea di fondo è che non esiste uno standard, a parte che le versioni più recenti usano numeri di versione più alti e che ogni numero di versione è univoco.
Leggi altre domande sui tag deployment software-updates software-distribution