Quando giudicheremo che il software che abbiamo creato è in versione 1.x o 2.x?

Per il software applicativo, il controllo delle versioni è un po 'arbitrario. La regola generale è:

• Per la correzione dei bug, cambia il terzo numero, generalmente chiamato livello patch. Tuttavia,
• Se si introducono alcune funzionalità aggiuntive o si apportano miglioramenti, modificare il secondo numero (numero di versione secondario). Tuttavia,
• Se introduci modifiche importanti e miglioramenti rivoluzionari, scegli una versione principale (ovvero 2.0.0)

La differenza tra maggiore e minore non è sempre chiara ed è talvolta guidata dal marketing. Anche se non raccomando queste pratiche, ecco alcuni esempi di vita reale:

• se le spese di manutenzione annuali coprono nuove versioni minori gratuitamente, ma hai investito molto in qualche sviluppo aggiuntivo, asserisci che si tratta di un importante cambiamento, quindi per rilanciare il bancomat.

• se hai una versione brillante che hai appena reso un po 'più luminoso (quindi dovrebbe essere una revisione minore) ma il tuo principale concorrente è due versioni principali avanti, basta allineare la tua versione principale in modo da essere almeno alta. Se devi saltare una versione principale, non preoccuparti, trova solo alcune scuse per il PR.

Se stai cercando una buona guida, puoi adottare versioning semantico . È definito con precisione e largamente adottato. Il suo ambito è tuttavia limitato alle API, con l'obiettivo di consentire una migliore gestione delle dipendenze. Ma puoi generalizzarlo per il tuo software applicativo considerando non solo l'interfaccia di programmazione ma anche l'interfaccia utente.

La numerazione delle versioni non è mai stata ben definita e varia tra gli sviluppatori, quindi quanto segue è necessariamente approssimativo.

Il software più vecchio generalmente utilizzava un formato x.yy. Il primo numero era una major release, mentre il secondo numero era sub-releases. Questo era di solito un vero decimale con due numeri dopo il punto. Ogni volta che cambi il software, aggiungi .01 al numero o vai alla successiva .10 divisione per un cambiamento maggiore. Per piccoli aggiustamenti o correzioni di bug, potresti aumentare di 0,001 (ad es. 0,999- > 0,999). Il numero prima dei decimali cambia quando ritieni di apportare un cambiamento significativo, che - nel software commerciale - ti faresti pagare. In questo sistema 1.9 è una versione successiva a 1.10 e le cose hanno problemi asintotici quando ci si avvicina a 2.0. La versione 0.yy è riservata alla versione beta o ad altre versioni preliminari. 1.00 è il tuo primo tentativo di master o versione.

Ora è sempre più comune usare un sistema di numerazione x.y.z, dove x è il numero maggiore, y è il numero minore e z è una patch o un numero di build. Cambiamenti significativi aumentano di y, mentre correzioni di bug o modifiche insignificanti incrementano z. Quando cambi x, azzeri y e z di nuovo, e quando cambi y z z zero. L'incremento di x indica ancora una versione principale con modifiche nuove, eventualmente all'indietro incompatibili. In questo schema 1.10.1 c'è una versione successiva alla 1.9.7.

E poi c'è Knuth che in versione asintoticamente TeX verso Pi - Che è carino ma difficilmente il più in generale schema utile - e aziende come Microsoft che modificano casualmente i loro schemi di numerazione ogni paio di progetti.

Raccomando vivamente di utilizzare uno schema x.y.z per il nuovo software e lo schema di versioning semantico per le librerie.