Cosa rappresentano in genere i numeri in una versione (es. V1.9.0.1)?

Forse questa è una domanda sciocca, ma ho sempre supposto che ogni numero delineato da un punto rappresentasse un singolo componente del software. Se è vero, rappresentano mai qualcosa di diverso? Vorrei iniziare ad assegnare le versioni alle diverse build del mio software, ma non sono sicuro di come dovrebbe essere strutturato. Il mio software ha cinque componenti distinti.

Nella versione 1.9.0.1 :

• 1 : revisione principale (nuova interfaccia utente, molte nuove funzionalità, modifica concettuale, ecc.)

• 9 : Revisione minore (forse una modifica a una casella di ricerca, 1 funzione aggiunta, raccolta di correzioni di bug)

• 0 : Rilascio correzione bug

• 1 : Build number (se utilizzato): ecco perché vedi il framework .NET usando qualcosa come 2.0.4.2709

Non troverai molte app che scendono a quattro livelli, 3 di solito è sufficiente.

Esiste la specifica di versione semantica

Questo è il riassunto della versione 2.0.0:

Dato un numero di versione MAJOR.MINOR.PATCH, incrementare:

1. Versione MAJOR quando si apportano modifiche API incompatibili,
2. Versione MINORE quando si aggiunge funzionalità in modo compatibile con le versioni precedenti e
3. Versione PATCH quando si apportano correzioni di bug compatibili con le versioni precedenti.

Ulteriori etichette per i metadati pre-release e build sono disponibili come estensioni nel formato MAJOR.MINOR.PATCH.

Può essere molto arbitrario e differisce da prodotto a prodotto. Ad esempio, con la distribuzione Ubuntu, 8.04 si riferisce al 2008 aprile

Tipicamente, i numeri più (a sinistra) più a sinistra indicano un rilascio maggiore, e più si va a destra, più piccolo è il cambiamento in questione.

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

Più punti, minore è il rilascio. Non esiste un vero standard solido oltre a questo: può significare cose diverse in base a ciò che decidono i manutentori del progetto.

WordPress, ad esempio, segue queste linee:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

La versione 1.6 alla 2.0 sarebbe una grande release - funzionalità, modifiche all'interfaccia, grandi cambiamenti alle API, rottura di alcuni template 1.6 e plugin, ecc. La versione 2.0 alla 2.0.1 sarebbe una versione minore - forse correggendo un bug di sicurezza. La versione 2.0.2 alla 2.1 sarebbe una versione significativa - nuove funzionalità, in generale.

I numeri possono essere utili come descritto da altre risposte, ma considera come possono anche essere piuttosto insignificanti ... Sun, conosci SUN, java: 1.2, 1.3, 1.4 1.5 o 5, poi 6. Nei buoni vecchi numeri di versione di Apple II significa Qualcosa. Al giorno d'oggi, le persone rinunciano ai numeri di versione e scelgono nomi sciocchi come "Feisty fig" (o qualcosa del genere) e "hardy heron" e "europa" e "ganimede". Naturalmente questo è molto meno utile perché, finirai per rimanere senza lune di Giove prima di smettere di cambiare il programma, e dal momento che non esiste un ordine ovvio non puoi dire quale sia la novità.

Nella versione v1.9.0.1: questo è lo schema di versioning esplicito utilizzato quando non si desidera utilizzare il nome per le pre-release o compilare come -alpha, -beta.

1: versione principale che potrebbe interrompere la compatibilità con le versioni precedenti

9: Aggiunta di nuove funzionalità per supportare l'app insieme alla compatibilità con le versioni precedenti.

0: alcune correzioni di bug minori

1: numero build (numero pre-release)

ma al giorno d'oggi non troverai questo schema di versioning. Fai riferimento a Semantic Versioning [semver2.0] https://semver.org/

I numeri di versione di solito non rappresentano componenti separati. Per alcune persone / software i numeri sono abbastanza arbitrari. Per altri, parti diverse della stringa del numero di versione rappresentano cose diverse. Ad esempio, alcuni sistemi aumentano parti del numero di versione quando cambia un formato di file. Quindi V 1.2.1 è un formato file compatibile con tutte le altre versioni V 1.2 (1.2.2, 1.2.3, ecc.) Ma non con V 1.3. Alla fine dipende da te quale schema vuoi usare.

Di solito è:

MajorVersion.MinorVersion.Revision.Build

Dipende, ma la rappresentazione tipica è quella di major.minor.release.build .

Dove:

• major è la versione di rilascio principale del tuo software, pensa .NET 3.x
• minor è la versione di rilascio minore del tuo software, pensa .NET x.5
• Il rilascio è il rilascio di quella versione, in genere le correzioni di bug aumenteranno questo
• build è un numero che indica il numero di build che hai eseguito.

Ad esempio, 1.9.0.1, significa che è la versione 1.9 del tuo software, che segue 1.8 e 1.7, ecc. Dove 1.7, 1.8 e 1.9 in qualche modo in genere aggiungono piccole quantità di nuove funzionalità insieme a correzioni di bug. Dato che è xx0.x, è la versione iniziale di 1.9 ed è la prima build di quella versione.

Puoi anche trovare buone informazioni sull'articolo di Wikipedia sull'argomento .

Major.Minor.Bugs

(O qualche variazione su questo)

I bug sono generalmente correzioni di errori senza nuove funzionalità.

Minori sono alcuni cambiamenti che aggiungono nuove funzionalità ma non cambiano il programma in alcun modo importante.

Importante è un cambiamento nel programma che rompe le vecchie funzionalità o è così grande che in qualche modo cambia il modo in cui gli utenti dovrebbero usare il programma.

Tutti scelgono cosa vogliono fare con questi numeri. Sono stato tentato di chiamare le versioni abc poiché è comunque piuttosto sciocco. Detto questo, ciò che ho visto negli ultimi 25+ anni di sviluppo tende a funzionare in questo modo. Supponiamo che il tuo numero di versione sia 1.2.3.

Il "1" indica una revisione "maggiore". Di solito si tratta di una versione iniziale, di una modifica del set di funzionalità di grandi dimensioni o di una riscrittura di parti significative del codice. Una volta determinato il set di funzionalità e implementato almeno parzialmente, si passa al numero successivo.

"2" indica un rilascio all'interno di una serie. Spesso usiamo questa posizione per rimanere invischiati a funzionalità che non sono state introdotte nell'ultima versione principale. Questa posizione (2) indica quasi sempre un'aggiunta di funzionalità, di solito con correzioni di bug.

Il "3" nella maggior parte dei negozi indica un rilascio di patch / correzione di bug. Quasi mai, almeno dal punto di vista commerciale, ciò indica una significativa aggiunta di funzionalità. Se le funzionalità vengono visualizzate in posizione 3, probabilmente è perché qualcuno ha effettuato il check-in prima di sapere che dovevamo eseguire una versione di correzione di bug.

Oltre la posizione "3"? Non ho idea del perché le persone facciano quel genere di cose, diventa solo più confuso.

In particolare alcuni degli OSS là fuori gettano tutto questo fuori di testa. Ad esempio, la versione 10 di Trac è in realtà 0.10.XX Penso che molte persone nel mondo OSS o non abbiano fiducia o semplicemente non vogliano annunciare che hanno fatto un rilascio importante.

Dal file AssemblyInfo.cs di C # è possibile visualizzare quanto segue:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revision sarebbe la mia ipotesi.
Ma può variare notevolmente tra i prodotti.

Major.minor.point.build di solito. Maggiore e minore sono autoesplicativi, il punto è una versione per alcune correzioni minori e build è solo un identificatore di build.

Sì. Le versioni principali aggiungono nuove e grandi funzionalità, possono interrompere la compatibilità o avere dipendenze significativamente diverse, ecc.

Le versioni minori aggiungono anche funzionalità, ma sono versioni portate più piccole, a volte ridotte dalla versione beta principale.

Se esiste un terzo componente del numero di versione, di solito è per correzioni importanti e correzioni di sicurezza. Se ce ne sono di più, dipende davvero tanto dal prodotto che è difficile dare una risposta generale.

Il paradigma della maggiore release.minor release.bug fix è piuttosto comune, credo.

In alcuni contratti di supporto alle imprese è associato $$$ (o violazione della responsabilità contrattuale) al modo in cui è designata una determinata versione. Un contratto, ad esempio, potrebbe autorizzare un cliente a un certo numero di rilasci importanti in un periodo di tempo, o promettere che ci sarà meno di x numero di rilasci minori in un periodo o che il supporto continuerà a essere disponibile per così tanti stampa. Ovviamente, indipendentemente dal numero di parole inserite nel contratto per spiegare quale sia una versione principale rispetto a una versione minore, è sempre soggettiva e ci saranno sempre aree grigie, portando alla possibilità che il fornitore del software possa giocare al sistema battere tali disposizioni contrattuali.

Le persone non riconoscono sempre la sottile differenza tra i numeri di versione come 2.1, 2.0.1 o 2.10 - chiedi a un tecnico dell'assistenza quante volte hanno avuto problemi con questo. Gli sviluppatori sono orientati ai dettagli e hanno familiarità con le strutture gerarchiche, quindi questo è un punto cieco per noi.

Se possibile, esponi un numero di versione più semplice ai tuoi clienti.

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 .

Una combinazione di maggiore, minore, patch, build, patch di sicurezza, ecc.

I primi due sono maggiori e minori: il resto dipenderà dal progetto, dall'azienda e talvolta dalla comunità. In SO come FreeBSD, avrai 1.9.0.1_number per rappresentare una patch di sicurezza.

Dipende un po 'dalla lingua, Delphi e C # ad esempio hanno significati diversi.

Di solito, i primi due numeri rappresentano una versione maggiore e una minore, ovvero 1.0 per la prima versione reale, 1.1 per alcune importanti correzioni di bug e nuove funzionalità minori, 2.0 per una nuova versione di nuove funzionalità.

Il terzo numero può fare riferimento a una versione "davvero minore" o revisione. 1.0.1 è solo un piccolo bugfix a 1.0.0 per esempio. Ma può anche trasportare il numero di revisione dal sistema di controllo del codice sorgente o un numero in costante aumento che aumenta con ogni build. O un Datestamp.

Un po 'più di dettagli qui . "ufficialmente", in .net, i 4 numeri sono "Major.Minor.Build.Revision", mentre a Delfi ci sono "Major.Minor.Release.Build". Uso "Major.Minor.ReallyMinor.SubversionRev" per il mio controllo delle versioni.

Generalmente i numeri sono nel formato version.major.minor.hotfix, non i singoli componenti interni. Quindi v1.9.0.1 sarebbe la versione 1, versione principale 9 (di v1), versione minore (di v1.9) 0, hot fix 1 di (v1.9.0).

Il primo numero viene in genere indicato come il numero di versione principale. In pratica viene utilizzato per indicare cambiamenti significativi tra le build (ovvero quando si aggiungono molte nuove funzionalità, si aumenta la versione principale). I componenti con diverse versioni principali dello stesso prodotto probabilmente non sono compatibili.

Il numero successivo è il numero di versione minore. Può rappresentare alcune nuove funzionalità o una serie di correzioni di errori o piccole modifiche all'architettura. I componenti dello stesso prodotto che differiscono per il numero di versione minore possono o meno funzionare insieme e probabilmente non dovrebbero.

Il prossimo di solito è chiamato il numero di build. Questo può essere incrementato giornalmente, o con ogni build "rilasciata", o con ogni build affatto. Potrebbero esserci solo piccole differenze tra due componenti che differiscono solo per il numero di build e in genere possono funzionare bene insieme.

Il numero finale è generalmente il numero di revisione. Spesso questo viene utilizzato da un processo di compilazione automatico o quando si eseguono build "una tantum" usa e getta per i test.

Quando si incrementano i numeri di versione, dipende da te, ma devono sempre aumentare o rimanere gli stessi . È possibile fare in modo che tutti i componenti condividano lo stesso numero di versione o incrementare il numero di versione solo sui componenti modificati.

Il numero di versione di un software complesso rappresenta l'intero pacchetto ed è indipendente dai numeri di versione delle parti. La versione 3.2.5 di Gizmo potrebbe contenere la versione 1.2.0 di Foo e la versione 9.5.4 di Bar.

Quando si creano i numeri di versione, utilizzarli come segue:

1. Il primo numero è la versione principale. Se si apportano modifiche significative all'interfaccia utente o è necessario interrompere le interfacce esistenti (in modo che gli utenti debbano modificare il loro codice di interfaccia), è necessario passare alla nuova versione principale.

2. Il secondo numero dovrebbe indicare che sono state aggiunte nuove funzionalità o che qualcosa funziona diversamente internamente. (Ad esempio, il database Oracle potrebbe decidere di utilizzare una strategia diversa per il recupero dei dati, rendendo la maggior parte delle cose più veloce e alcune più lente.) Le interfacce esistenti dovrebbero continuare a funzionare e l'interfaccia utente dovrebbe essere riconoscibile.

3. La numerazione delle versioni dipende anche dalla persona che scrive il software: Oracle utilizza cinque (!) Gruppi, vale a dire. una versione Oracle è qualcosa come 10.1.3.0.5. Dal terzo gruppo in poi, è necessario introdurre solo correzioni di bug o lievi modifiche nella funzionalità.

quelli che variano di meno sarebbero i primi due, per major.minor, dopodiché può essere qualsiasi cosa, dalla compilazione, revisione, rilascio, a qualsiasi algoritmo personalizzato (come in alcuni prodotti MS)

Ogni organizzazione / gruppo ha il proprio standard. L'importante è attenersi a qualunque notazione scegliate altrimenti i vostri clienti saranno confusi. Detto questo, ho usato normalmente 3 numeri:

x.yz.bbbbb. Dove: x: è la versione principale (principali nuove funzionalità) y: è il numero di versione minore (piccole nuove funzionalità, piccoli miglioramenti senza modifiche all'interfaccia utente) z: è il service pack (sostanzialmente uguale a xy ma con alcune correzioni di errori bbbb: è il numero di build ed è davvero visibile solo dalla "about box" con altri dettagli per l'assistenza clienti. bbbb è un formato gratuito e ogni prodotto può usare il proprio.

Ecco cosa usiamo:

1. Primo numero = era generale del sistema. Cambia ogni due anni e in genere rappresenta un cambiamento fondamentale nella tecnologia, nelle funzionalità del client o in entrambi.
2. Secondo numero = revisione dello schema del database. Un incremento di questo numero richiede una migrazione del database e quindi una modifica significativa (o i sistemi si replicano e quindi cambiare la struttura del database richiede un attento processo di aggiornamento). Reimposta su 0 se il primo numero cambia.
3. Terzo numero = modifica solo software. Questo di solito può essere implementato su base client per cliente poiché lo schema del database è invariato. Reimposta a zero se il secondo numero cambia.
4. Numero di versione di sovversione. Lo compiliamo automaticamente al momento della compilazione utilizzando lo strumento TortoiseSVN. Questo numero non si ripristina mai ma aumenta continuamente. Usando questo possiamo sempre ricreare qualsiasi versione.

Questo sistema ci sta bene perché ogni numero ha una funzione chiara e importante. Ho visto altre squadre alle prese con la domanda sul numero maggiore / sul numero minore (quanto è grande un cambiamento importante) e non ne vedo il vantaggio. Se non è necessario tenere traccia delle revisioni del database, passare a un numero di versione di 3 o 2 cifre e semplificare la vita!

versione: v1.9.0.1

dove-

. v è l'abbreviazione della versione. Varia a seconda della compagnia, dipende dalla nomenclatura adottata nella sua organizzazione. Potrebbe tacere in alcune organizzazioni come 1.9.0.1

. 1 indica la versione principale, verrà aggiornato sulla modifica dell'architettura in stack di applicazioni, infrastruttura (piattaforma) o interfaccia di reti esposte

. 9 inciti minori, saranno aggiornati sull'attività come l'aggiunta di nuovi componenti come interfaccia utente, API, database ecc; sotto un'architettura specifica

. 0 indica funzionalità, verrà aggiornato su eventuali miglioramenti sui componenti esistenti (interfaccia utente, API, database ecc.)

. 1 indica il contatore di build in tutte le fasi major, minor e feature. Include inoltre aggiornamenti rapidi post-produzione.