Cosa significano veramente le versioni di aggiornamento?

18

Molti aggiornamenti software seguono lo schema da v0.1 a v0.2 a v2.6.5.6 . Cosa significano veramente questi "aggiornamenti" del software? Esiste sempre uno standard industriale o i programmatori continuano a innalzare l'aggiornamento # o ad aggiungere più decimali?

deployment software-updates software-distribution

— James Mertz
fonte

12

@ S.Lott Dato che sono abbastanza nuovo sulla scena della programmazione, non conoscerei le specificità. Questo è il modo migliore per chiedere che potrei inventarmi.

— James Mertz,

9

@ S. Lott, tagliato sul caffeina signore, ti sta rendendo irritabile.

— ocodo,

2

@ S.Lott sentiti libero di modificare come ritieni opportuno migliorare la domanda. Sento che sai cosa sto cercando. Tuttavia, ritengo che le risposte fornite siano state molto buone. Sento anche, a giudicare dai voti positivi del mio precedente commento, che ho fatto del mio meglio e che la domanda è ok così com'è. Comunque accolgo con favore le critiche e le modifiche. Fai come ritieni opportuno. Per me, lo sto lasciando da solo.

— James Mertz,

1

@ S.Lott La domanda mi sembra abbastanza chiara. Non credo che elencare una specifica organizzazione di standardizzazione sarebbe un notevole miglioramento. In caso contrario, non esitare a modificare. Hai il rappresentante per questo.

— Adam Lear

3

@ S.Lott: "Esiste uno standard industriale" va benissimo. Sì, ci sono standard di settore! Non importa chi li scrive: KronoS vuole sapere cosa significano le versioni, è sua la scelta di specificare quanto dettagliare va ... Forse avresti dovuto menzionare che ritieni che la domanda sia ampia? Il solo martellamento dei dettagli non lo rende chiaro all'utente, dicendo a un utente di definirlo: la parola non lo rende chiaro all'utente, dicendo che non ha senso dopo che il tuo primo commento non lo rende chiaro all'utente.

— Tamara Wijsman,

16

Come ha detto Shaun, non esiste davvero uno standard. Alcune aziende hanno pratiche di versioning migliori di altre (ho avuto a che fare con venditori che saltano i principali numeri di versione e altri che sono bloccati sulla stessa xy diverse versioni in seguito).

Detto questo, l'inventore di Gravatars e cofondatore di GitHub ( Tom Preston-Werner ) ha scritto un documento per " Semantic Versioning " che merita di essere letto.

Ecco l'eccezione dell'intro:

Come soluzione a questo problema, propongo un semplice insieme di regole e requisiti che determinano il modo in cui i numeri di versione vengono assegnati e incrementati. Perché questo sistema funzioni, devi prima dichiarare un'API pubblica. Ciò può consistere in documentazione o essere imposto dal codice stesso. Indipendentemente da ciò, è importante che questa API sia chiara e precisa. Una volta identificata l'API pubblica, le comunichi le modifiche con incrementi specifici al numero di versione. Considera un formato di versione di XYZ (Major.Minor.Patch). Le correzioni di bug che non influiscono sull'API aumentano la versione della patch, le aggiunte / modifiche all'API compatibili all'indietro aumentano la versione secondaria e le modifiche all'API incompatibili all'indietro aumentano la versione principale.

Chiamo questo sistema "Semantic Versioning". In base a questo schema, i numeri di versione e il modo in cui cambiano trasmettono significato sul codice sottostante e su ciò che è stato modificato da una versione all'altra.

— Dan McGrath
fonte

7

Con 4 cifre di solito è MajorV.MinorV.PatchNum.BuildNum, almeno dove lavoro.

Personalmente preferisco lo schema di versione di Ubuntu - rende la vita molto più semplice.

— Lavoro
fonte

Qual è il loro schema? Perché li preferisci?

— James Mertz,

3

Ubuntu 10.10 = ottobre 2010, Ubuntu 10.04 = aprile 2010, Ubuntu 11.04 = aprile 2011, Ubuntu 9.10 = ottobre 2009, ecc. Questo è menzionato in quel link Wikipedia da Shaun.

— Lavoro

2

La cosa bella dell'uso delle date come numeri di versione è che, a meno che non si verifichi un paradosso temporale strano, il numero di versione sarà sempre nell'ordine corretto. Per la maggior parte di noi, è più facile ricordare che oggi è il 2011.02.13 piuttosto che cercare di capire quale versione della nuova versione dovrebbe essere.

— jmort253,

@ jmort245, esattamente! I sistemi creati dall'uomo sono piuttosto disordinati. Le banche impazzite pensano che ci siano 360, 362, 365, 366, ecc. Giorni in un anno. Il sistema di versioning è ancora un'altra di quelle stupide creazioni. I timestamp non ci fanno pensare, anche se 20050207 impiega un po 'più tempo a leggere e capire di 502. Quale software viene rilasciato più spesso di una volta al mese?

— Giobbe

2

@job: Ma l'utilizzo delle versioni ti consente di associare funzionalità a specifiche versioni principali o secondarie. Quindi, se ho la versione 2, so di avere la funzione X mentre la versione 1 non ha la versione X.

— Martin York,

6

La versione breve è che non esiste uno standard e le aziende fanno quello che vogliono. In sostanza, più numeri hai, più piccola è la quantità di modifiche che ciascun numero rappresenta. Comunemente, vedrai almeno la versione xy, in cui xa change in x indica le versioni principali (ottimizzazione / implementazione delle funzionalità principali) e y indica versioni secondarie (modifiche significative o correzioni di errori). Più decimali dopo questi due possono significare cose diverse internamente a un'azienda, sebbene spesso ruotino attorno a build o patch di contenuti minori che rappresentano correzioni più veloci e più piccole.

Wikipedia ha un articolo che tratta questo in modo più dettagliato.

— Shaun
fonte

3

Lo scopo dei numeri di versione è fornire un riferimento per i rapporti sui 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 potenza come 10 (numero romano X) sono davvero accattivanti. Alcune persone usano alcune varianti del versioning semantico:

MAJOR.MINOR.MICRO.BUILD

Incrementi importanti: modifiche incompatibili o riprogettazione completa dell'interfaccia utente
Incrementi minori: nuove funzionalità aggiunte, compatibili con le versioni precedenti con lo stesso numero di versione principale
Micro incrementi: rilascio correzione bug
Numero build: generato dal compilatore o estratto dal controllo versione

Molti gruppi rilasciano il numero BUILD nelle loro versioni. Di solito è utile solo tra gruppi di test e di sviluppo.

Alcuni gruppi aggiungono semantica aggiuntiva, come gli incrementi MINOR con numero dispari sono per build sperimentali e gli incrementi MINOR con numero pari sono per le versioni di produzione (il kernel Linux utilizza questo approccio).

La linea di fondo è che non esiste uno standard, tranne che le versioni più recenti utilizzano numeri di versione più alti e che ogni numero di versione è univoco.

— Berin Loritsch
fonte