it-swarm.it

Cosa rappresentano in genere i numeri in una versione (ad esempio v1.9.0.1)?

Forse questa è una domanda stupida, ma ho sempre pensato che ogni numero delineato da un periodo rappresentasse un singolo componente del software. Se è vero, rappresentano sempre qualcosa di diverso? Mi piacerebbe iniziare ad assegnare versioni alle diverse versioni del mio software, ma non sono sicuro di come dovrebbe essere strutturato. Il mio software ha cinque componenti distinti.

110
BeachRunnerFred

Nella versione 1.9.0.1:

  • 1 : Revisione principale (nuova interfaccia utente, molte nuove funzionalità, modifiche concettuali, ecc.)

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

  • 0 : Rilascio delle correzioni dei bug

  • 1 : Numero di build (se usato) - ecco perché si vede il framework .NET usando qualcosa come 2.0.4.2709

Non troverai molte app che scendono a quattro livelli, generalmente 3 sono sufficienti.

159
Dillie-O

Esiste la Specifica di Versioning semantica

Questo è il riassunto della versione 2.0:

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

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

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

14
magyk

Può essere molto arbitrario e si differenzia da un prodotto all'altro. Ad esempio, con la distribuzione di Ubuntu, 8.04 fa riferimento a 2008.Aprile

In genere i numeri (maggiori) a sinistra indicano una versione principale e più si va a destra, minore è il cambiamento.

13
rkabir
11

I numeri possono essere utili come descritto da altre risposte, ma considera come possono essere anche piuttosto privi di significato ... Sun, conosci Sun, Java: 1.2, 1.3, 1.4 1.5 o 5 poi 6 . Nel buon vecchio Apple II i numeri di versione significano qualcosa. Al giorno d'oggi, le persone stanno rinunciando ai numeri di versione e andando con nomi sciocchi come "Feisty fig" (o qualcosa del genere) e "airone robusto" e "europa" e "ganimede". Ovviamente questo è molto meno utile perché, finirai per cambiare il programma, finirai per esaurire le lune di Giove, e dal momento che non c'è un ordinamento evidente non puoi dire quale è più recente.

8
stu

Più punti, più minore è il rilascio. Non c'è un vero e proprio standard oltre a quello - 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 da 1.6 a 2.0 sarebbe una grande release: funzionalità, modifiche all'interfaccia, modifiche importanti alle API, rottura di alcuni modelli e plug-in 1.6, ecc., Da 2.0 a 2.0.1 sarebbe una versione minore, forse la correzione di un bug di sicurezza. 2.0.2 a 2.1 sarebbe una versione significativa - nuove funzionalità, in generale.

7
ceejayoz

I numeri possono significare tutto ciò che vuoi, anche se di solito non sono correlati ai singoli componenti, ma piuttosto alle modifiche maggiori o minori rispetto alla manutenzione nella tua versione.

Dai un'occhiata a queste risorse:
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html

Saluti

4
Alvaro Rodriguez

I numeri di versione in genere non rappresentano componenti separati. Per alcune persone/software i numeri sono abbastanza arbitrari. Per altri, diverse parti 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. In fin dei conti spetta a te quale schema vuoi usare.

3
user9385

Dal file C # AssemblyInfo.cs puoi vedere 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.*")]
2
Thomas Jespersen

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

2
Fire Lancer

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

Dove:

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

Quindi, ad esempio, 1.9.0.1, significa che è la versione 1.9 del tuo software, seguendo 1.8 e 1.7, ecc. Dove 1.7, 1.8 e 1.9 in genere aggiungono in genere piccole quantità di nuove funzionalità oltre a correzioni di errori. Poiché è x.x.0.x, è la versione iniziale di 1.9 ed è la prima build di quella versione.

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

Major.Minor.Bugs

(O qualche variazione su quello)

I bug sono solitamente correzioni di bug senza nuove funzionalità.

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

Major è 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.

2
emeryc

Ognuno sceglie ciò che vuole fare con questi numeri. Sono stato tentato di chiamare i rilasci a.b.c dato che è piuttosto sciocco comunque. Detto questo, quello 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.

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

Il "2" indica un rilascio all'interno di una serie. Spesso usiamo questa posizione per essere coinvolti in funzioni che non sono state incluse nell'ultima versione principale. Questa posizione (2) indica quasi sempre un'aggiunta di funzionalità, solitamente con correzioni di errori.

Il "3" nella maggior parte dei negozi indica una patch release/bug fix. Quasi mai, almeno dal punto di vista commerciale, questo indica una caratteristica significativa aggiunta. Se le caratteristiche appaiono nella posizione 3, probabilmente è perché qualcuno ha verificato qualcosa prima che sapessimo che dovevamo fare una versione di correzione di bug.

Oltre la posizione "3"? Non ho idea del perché la gente faccia quel genere di cose, diventa solo più confusa.

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

1
mclain

Le persone non sempre riconoscono la sottile differenza tra i numeri di versione come 2.1, 2.0.1 o 2.10 - chiedi a un tecnico di supporto 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, esporre un numero di versione più semplice ai propri clienti.

1
Mark Ransom

Il paradigma della versione principale release.minor release.bug è piuttosto comune, penso. 

In alcuni contratti di supporto aziendale, ci sono $$$ (o violazione della responsabilità contrattuale) associati a come viene designata una particolare release. Un contratto, ad esempio, potrebbe autorizzare un cliente a un certo numero di versioni principali 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à ad essere disponibile per così tanti stampa. Ovviamente, non importa quante parole vengono inserite nel contratto per spiegare che una major release è una release secondaria, è sempre soggettiva e ci saranno sempre aree grigie - portando alla possibilità che il fornitore di software possa far giocare il sistema a battere tali disposizioni contrattuali.

1
Will M

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 di correzione di bug deve preservare la compatibilità binaria, di origine e di serializzazione.

Rilasci minori significano cose diverse per progetti diversi, ma di solito non hanno bisogno di preservare la compatibilità con la fonte.

I numeri di versione principali possono rompere tutte e tre le forme.

Ho scritto di più sulla logica qui .

1
Craig P. Motlin

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

1
Cody Brocious

Di solito è:

MajorVersion.MinorVersion.Revision.Build

1
Jason Punyon

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

Le versioni minori aggiungono anche funzionalità, ma sono versioni con porting ridotte, a volte ridotte, dalla versione beta major.

Se esiste un componente del terzo numero di versione, in genere si tratta di correzioni importanti e correzioni di sicurezza. Se ce ne sono di più, in realtà dipende tanto dal prodotto che è difficile dare una risposta generale.

1
Paweł Hajdan

Il primo numero viene in genere definito come il numero di versione principale. È fondamentalmente utilizzato per indicare cambiamenti significativi tra le build (ad esempio quando si aggiungono molte nuove funzionalità, si incrementa la versione principale). I componenti con versioni principali diverse 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 bug o piccole modifiche all'architettura. I componenti dello stesso prodotto che differiscono per il numero di versione minore potrebbero non funzionare o potrebbero non funzionare insieme e probabilmente non dovrebbero.

Il prossimo è solitamente chiamato il numero di build. Questo può essere incrementato ogni giorno, o con ogni build "rilasciata", o con ogni build. 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 è solitamente il numero di revisione. Spesso questo viene utilizzato da un processo di compilazione automatico o quando si realizzano build "one-off" per il testing.

Quando aumenti i tuoi numeri di versione dipende da te, ma dovrebbero sempre incrementare o rimanere lo stesso . È possibile avere tutti i componenti condividono lo stesso numero di versione o solo incrementare il numero di versione sui componenti modificati.

0
Bob King

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 Foo versione 1.2.0 e Bar versione 9.5.4.

Quando crei i numeri di versione, usali come segue:

  1. Il primo numero è la versione principale. Se si apportano modifiche significative all'interfaccia utente o si desidera interrompere le interfacce esistenti (in modo che gli utenti debbano modificare il proprio 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 in modo diverso 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 cose più lente.) Le interfacce esistenti dovrebbero continuare a funzionare e l'interfaccia utente dovrebbe essere riconoscibile. 

  3. La numerazione della versione è a discrezione della persona che scrive il software - Oracle utilizza cinque gruppi (!), Ad es. una versione Oracle è qualcosa come 10.1.3.0.5. Dal terzo gruppo verso il basso, dovresti introdurre solo correzioni di bug o modifiche minori nella funzionalità. 

0
Sten Vesterli
0
Sijin

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

0
BlackTigerX

Ecco cosa usiamo:

  1. Primo numero = Era generale del sistema. Cambia ogni due anni e rappresenta in genere un cambiamento fondamentale nella tecnologia, nelle funzionalità del client o in entrambi.
  2. Secondo numero = revisione dello schema del database. Un incremento in questo numero richiede una migrazione del database e quindi un cambiamento significativo (o la replica dei sistemi e quindi la modifica della struttura del database richiede un accurato processo di aggiornamento). Reimposta a 0 se il primo numero cambia.
  3. Terzo numero = solo il software cambia. Di solito, questo può essere implementato su un client per cliente in quanto lo schema del database è invariato. Reimposta su zero se cambia il secondo numero.
  4. Numero di versione di Subversion. Lo compiliamo automaticamente su build utilizzando lo strumento TortoiseSVN. Questo numero non si reimposta mai ma incrementa continuamente. Usando questo possiamo sempre ricreare qualsiasi versione.

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

0
Ewan Makepeace

Nella versione v1.9.0.1: Questo è lo schema di versioning esplicito usato quando non si vuole usare il nome per le versioni preliminari o come build -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 retrocompatibilità con la versione precedente.

0: alcune correzioni di bug minori

1: numero di build (numero di pre-rilascio)

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

0
Mehul Sancheti

Ogni organizzazione/gruppo ha il proprio standard. L'importante è che ti attenga a qualunque notazione tu scelga altrimenti i tuoi clienti saranno confusi. Detto questo, ho usato normalmente 3 numeri:

x.yz.bbbbb. Dove: X: è la versione principale (maggiori novità) Y: è il numero di versione minore (piccole nuove funzionalità, piccoli miglioramenti senza modifiche all'interfaccia utente) Z: è il service pack (fondamentalmente lo stesso come xy ma con alcune correzioni di bug bbbb: è il numero di build e solo realmente visibile dal "riquadro informazioni" con altri dettagli per l'assistenza clienti. bbbb è un formato gratuito e ogni prodotto può utilizzarlo.

0
Vasco Duarte

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

I primi due sono maggiori e minori - il resto dipenderà dal progetto, dalla compagnia e talvolta dalla comunità. In OS come FreeBSD, avrai il numero 1.9.0.1 per rappresentare una patch di sicurezza.

0
Loren Segal

Dipende un po 'dal linguaggio, Delphi e C # per esempio hanno significati diversi.

Di solito, i primi due numeri rappresentavano una versione maggiore e una minore, vale a dire 1.0 per la prima versione reale, 1.1 per alcune correzioni di bug importanti e nuove funzionalità minori, 2.0 per una nuova grande funzione.

Il terzo numero può riferirsi a una versione "veramente minore" o revisione. 1.0.1 è solo un bugfix molto piccolo per 1.0.0 per esempio. Ma può anche trasportare il numero di revisione dal tuo sistema di controllo del codice sorgente o un numero sempre crescente che aumenta a ogni build. O un Datestamp.

Un po 'più in dettaglio qui . "ufficialmente", in .net, i 4 numeri sono "Major.Minor.Build.Revision", mentre in Delphi ci sono "Major.Minor.Release.Build". Io uso "Major.Minor.ReallyMinor.SubversionRev" per il mio controllo delle versioni.

0
Michael Stum

Generalmente, il numero è nel formato di version.major.minor.hotfix, non di singoli componenti interni. Quindi v1.9.0.1 sarebbe versione 1, versione principale 9 (di v1), versione secondaria (di v1.9) 0, hot fix 1 di (v1.9.0).

0
Scott Bevington