Cosa rappresentano tipicamente i numeri in una versione (ad es.v1.9.0.1)?

https://stackoverflow.com/questions/65718

versions

09-06-2019
|

Domanda

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

Soluzione

Nella versione 1.9.0.1:

1:Revisione importante (nuova interfaccia utente, molte nuove funzionalità, cambiamento concettuale, ecc.)
9:Revisione minore (forse una modifica a una casella di ricerca, 1 funzionalità aggiunta, raccolta di correzioni di bug)
0:Rilascio di correzione di bug
1:Numero di build (se utilizzato): ecco perché vedi il framework .NET che utilizza qualcosa come 2.0.4.2709

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

Altri suggerimenti

C'è la Specifica del Versioning Semantico

Questo è il riassunto della versione 2.0:

Dato un numero di versione MAJOR.MINOR.PATCH, incrementare:
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 costruzioni sono disponibili come estensioni al formato Major.Minor.Patch.

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

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

major.minor[.maintenance[.build]]

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

I numeri possono essere utili come descritto da altre risposte, ma considera come possono anche essere piuttosto privi di significato...Sun, conosci SUN, Java:1.2, 1.3, 1.4 1.5 o 5 poi 6.Nella vecchia versione di Apple II i numeri significavano qualcosa.Al giorno d'oggi, le persone rinunciano ai numeri di versione e scelgono nomi stupidi come "Feisty fig" (o qualcosa del genere) e "hardy airone" e "europa" e "ganimede".Ovviamente questo è molto meno utile perché finirai le lune di Giove prima di smettere di cambiare il programma e poiché non esiste un ordine ovvio non puoi dire quale sia la più recente.

Più punti, più minore sarà il rilascio.Non esiste uno standard solido e reale oltre a questo: può significare cose diverse in base a ciò che decidono i manutentori del progetto.

WordPress, ad esempio, va in questa direzione:

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 plugin della versione 1.6, ecc.La versione da 2.0 a 2.0.1 sarebbe una versione minore, forse risolverebbe un bug di sicurezza.Da 2.0.2 a 2.1 sarebbe una versione significativa: nuove funzionalità, in generale.

I numeri possono significare tutto ciò che vuoi, anche se di solito non sono correlati ai singoli componenti ma piuttosto al rapporto tra maggiore e maggiore.minore vs.modifiche di manutenzione nella 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

I numeri di versione solitamente 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 il formato di un file.Quindi il formato V 1.2.1 è 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 utilizzare.

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

Dove:

maggiore è la versione principale del tuo software, pensa a .NET 3.x
minore è la versione secondaria del tuo software, pensa .NET x.5
pubblicazione è il rilascio di quella versione, in genere le correzioni di bug lo incrementeranno
costruire è un numero che indica il numero di build eseguite.

Quindi, ad esempio, 1.9.0.1 significa che è la versione 1.9 del tuo software, successiva a 1.8 e 1.7, ecc.dove 1.7, 1.8 e 1.9 in qualche modo tipicamente aggiungono piccole quantità di nuove funzionalità insieme a correzioni di bug.Poiché è x.x.0.x, è la versione iniziale della 1.9 ed è la prima build di quella versione.

Puoi anche trovare buone informazioni su Articolo di Wikipedia sull'argomento.

Bug maggiori.minori

(O qualche variazione su questo)

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

Minore è una modifica che aggiunge nuove funzionalità ma non modifica il programma in alcun modo.

Importante è un cambiamento nel programma che interrompe le vecchie funzionalità o è così grande da cambiare in qualche modo il modo in cui gli utenti dovrebbero utilizzare il programma.

Dal file C# AssemblyInfo.cs è 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.Major e minor sono autoesplicativi, point è un rilascio per alcune correzioni di bug minori e build è solo un identificatore di build.

Di solito è:

MajorVersion.MinorVersion.Revision.Build

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

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

Se è presente un terzo componente del numero di versione, di solito è per importanti correzioni di bug e correzioni di sicurezza.Se ce ne sono altri, dipende davvero così tanto dal prodotto che è difficile dare una risposta generale.

Ognuno sceglie cosa vuole fare con questi numeri.Sono stato tentato di chiamare le versioni a.b.c poiché è comunque piuttosto sciocco.Detto questo, ciò che ho visto negli ultimi 25 e più 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 "importante".Di solito si tratta di una versione iniziale, di una modifica ampia del set di funzionalità o di una riscrittura di porzioni significative del codice.Una volta determinato e implementato almeno parzialmente il set di funzionalità, si passa al numero successivo.

Il "2" indica un'uscita all'interno di una serie.Spesso utilizziamo questa posizione per restare intrappolati in funzionalità che non erano presenti nell'ultima versione principale.Questa posizione (2) indica quasi sempre l'aggiunta di una funzionalità, solitamente con correzioni di bug.

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

Oltre la posizione "3"?Non ho idea del perché le persone facciano questo 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.X.X.Penso che molte persone nel mondo OSS manchino di fiducia o semplicemente non vogliano annunciare di aver realizzato una major release.

Penso che il paradigma della correzione di major release.minor release.bug sia piuttosto comune.

In alcuni contratti di supporto aziendale è presente una $$$ (o violazione della responsabilità contrattuale) associata al modo in cui viene designata una particolare versione.Un contratto, ad esempio, potrebbe dare diritto a un cliente a un certo numero di versioni principali in un periodo di tempo, o promettere che ci saranno meno di x numero di versioni minori in un periodo, o che il supporto continuerà a essere disponibile per così tante versioni rilascia.Naturalmente, non importa quante parole vengono inserite nel contratto per spiegare cos'è una versione principale rispetto a una versione minore, è sempre soggettivo e ci saranno sempre aree grigie, che portano alla possibilità che il fornitore del software possa ingannare il sistema per battere tali disposizioni contrattuali.

Le persone non sempre riconoscono la sottile differenza tra numeri di versione come 2.1, 2.0.1 o 2.10: chiedi a una persona del supporto tecnico quante volte hanno avuto problemi con questo.Gli sviluppatori sono attenti ai dettagli e hanno familiarità con le strutture gerarchiche, quindi questo è un punto cieco per noi.

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

Nel caso di una libreria, il numero di versione indica il file livello di compatibilità tra due versioni e quindi quanto sarà difficile un aggiornamento.

Una versione di correzione di bug deve preservare la compatibilità del binario, dell'origine e della 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 motivazione Qui.

Nella versione v1.9.0.1:Questo è lo schema di controllo delle versioni esplicito usato quando non vuoi usare il nome per le pre-release o creare build 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 controllo delle versioni. Fai riferimento al controllo delle versioni semantico [semver2.0]https://semver.org/

Una combinazione di major, minor, patch, build, patch di sicurezza, ecc.

I primi due sono maggiori e minori: il resto dipenderà dal progetto, dall'azienda e talvolta dalla comunità.Nei sistemi operativi 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, cioè1.0 per la prima vera versione, 1.1 per alcune importanti correzioni di bug e nuove funzionalità minori, 2.0 per una grande nuova versione di funzionalità.

Il terzo numero può riferirsi a una versione o revisione "realmente minore".La versione 1.0.1 è solo una piccola correzione di bug rispetto alla versione 1.0.0, ad esempio.Ma può anche contenere il numero di revisione dal tuo sistema di controllo del codice sorgente o un numero sempre crescente che aumenta con ogni build.O un timbro data.

Un po' più di dettaglio Qui."ufficialmente", in .net, i 4 numeri sono "Major.Minor.Build.Revision", mentre in Delphi ci sono "Major.Minor.Release.Build".Utilizzo "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, hotfix 1 di (v1.9.0).

Il primo numero viene generalmente indicato come numero di versione principale.Fondamentalmente viene utilizzato per denotare cambiamenti significativi tra le build (ad es.quando aggiungi molte nuove funzionalità, incrementi la versione principale).I componenti con versioni principali diverse dello stesso prodotto probabilmente non sono compatibili.

Il numero successivo è il numero della 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 funzionare insieme o meno e probabilmente non dovrebbero.

Il successivo è solitamente chiamato numero di build.Questo può essere incrementato quotidianamente, 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 creazione automatico o quando si realizzano build usa e getta "una tantum" per i test.

Dipende da te quando incrementare i numeri di versione, ma dovrebbero sempre incremento O restare lo stesso.È possibile fare in modo che tutti i componenti condividano lo stesso numero di versione o solo incrementare il numero di versione sui componenti modificati.

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

Quando crei i numeri di versione, usali come segue:

Il primo numero è la versione principale.Se apporti modifiche significative all'interfaccia utente o hai bisogno di interrompere le interfacce esistenti (in modo che i tuoi utenti debbano modificare il codice dell'interfaccia), dovresti passare alla nuova versione principale.
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ù veloci e alcune più lente.) Le interfacce esistenti dovrebbero continuare a funzionare e l'interfaccia utente dovrebbe essere riconoscibile.
La numerazione successiva della versione spetta alla persona che scrive il software: Oracle utilizza cinque (!) gruppi, ad es.una versione Oracle è qualcosa come 10.1.3.0.5.Dal terzo gruppo in giù, dovresti introdurre solo correzioni di bug o modifiche minori alla funzionalità.

Note sul processo di creazione del software

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

Ogni organizzazione/gruppo ha il proprio standard.L'importante è attenersi alla notazione scelta, altrimenti i clienti rimarranno confusi.Detto questo normalmente utilizzo 3 numeri:

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

Ecco cosa utilizziamo:

Primo numero = Era complessiva del sistema.Cambia ogni due anni e in genere rappresenta un cambiamento fondamentale nella tecnologia, nelle funzionalità del client o in entrambi.
Secondo numero = revisione dello schema del database.Un incremento in questo numero richiede una migrazione del database e quindi rappresenta un cambiamento significativo (o i sistemi si replicano e quindi la modifica della struttura del database richiede un attento processo di aggiornamento).Reimposta su 0 se cambia il primo numero.
Terzo numero = modifica solo del software.Questo di solito può essere implementato cliente per cliente poiché lo schema del database è invariato.Si reimposta su zero se cambia il secondo numero.
Numero di versione di Subversion.Lo popoliamo automaticamente al momento della creazione utilizzando lo strumento TortoiseSVN.Questo numero non si azzera mai ma aumenta continuamente.Usandolo possiamo sempre ricreare qualsiasi versione.

Questo sistema ci sta servendo bene perché ogni numero ha una funzione chiara e importante.Ho visto altri team alle prese con la questione del numero maggiore/minore (quanto è grande un cambiamento) e non ne vedo il vantaggio.Se non hai bisogno di tenere traccia delle revisioni del database, vai al numero di versione di 3 o 2 cifre e semplifica la vita!

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow