Domanda Come fai a sapere quale numero di versione utilizzare?


Eccone uno che mi sono sempre chiesto ...

Per favore scusate la mia ingenuità, ma - Come decidete quale numero di versione nominare il vostro software?

Presumo, quando qualcuno crea una versione "finale" di un'applicazione / programma, è la versione 1.0? - Allora, cosa succede quando lo aggiorni, come decidi di chiamarlo 1.1 o 1.03 ecc. Ecc.

Questo è principalmente per lo sviluppatore?


44
2017-12-28 17:32


origine


risposte:


Di recente ho sentito una strategia di versioning pithier, che ho incontrato per la prima volta Account medio di Eric Elliot. È più importante per la versione delle librerie che i numeri di versione dei clienti, ma ha il vantaggio della semplicità. Utilizzare un numero di versione in tre parti, in cui ogni numero indica:

breaking.feature.fix

  • rottura: Qualcosa è cambiato che significa che il codice / le aspettative devono cambiare
  • caratteristica: Viene aggiunto qualcosa di nuovo, ma il vecchio codice / aspettative funzionerà ancora bene.
  • fissare: Niente di nuovo, ma un bug è stato corretto.

Lascio la mia vecchia risposta di seguito, poiché è ancora rilevante per le versioni rivolte ai clienti.


Io tendo a pesare le cifre significative come segue ....

w.x.y.z (o w.xyz)

  • w - Versione principale, con molte novità Caratteristiche. Un aggiornamento a pagamento. Il primo la versione pubblica del software è 1.X (le versioni pre-release sono 0.X)
  • X - Rilascio significativo, ma senza nuove caratteristiche rivoluzionarie.
  • y - Rilasci di bugfix
  • z - Patchlevel rilasci (che fissa un bug di emergenza, forse solo per un cliente).

Se scegli di utilizzare il formato w.xyz, ottieni solo 9 cifre prima dell'overflow. Tuttavia, se lo rilasci spesso, potresti avere un problema più grande.

Illustriamo con FooApp, il mio nuovo prodotto!

  • 0.9 - La prima beta pubblica
  • 0.91 - La seconda beta pubblica
  • 0.911 - La versione beta di emergenza per risolvere un crash sul Motorola 68010
  • 1.0 - La prima versione pubblica
  • 1.1 - Aggiunta la nuova funzionalità di BlahBaz
  • 1.11 - Correzione di errori
  • 2.0 - Interfaccia completamente rinnovata.

46
2017-12-28 17:37



Jeff Atwood ha un post sul blog a questo proposito, dove sostiene semplicemente l'uso delle date e di non confondere l'utente con i numeri di versione. Tuttavia, egli discute l'approccio che Microsoft ha adottato: Utilizzare le date per determinare i numeri di versione. Entra in un po 'di profondità nel suo post, quindi non duplicherò il suo lavoro qui. Per quanto riguarda il controllo delle versioni:

Versioni (almeno in .NET, andare in questo modo):

1.2.3.4 dove:

1 è il versione principale
2 è il rilascio minore
3 è il costruire numero
4 è il revisione numero

Major Release - Significa un sistema 'completo' con qualsiasi funzione che la versione avrebbe dovuto avere. Normalmente tutte le successive versioni "principali" sono riscritte, o modifiche all'architettura, o (scusate la ridondanza) importanti modifiche al software.

Rilascio secondario - Significa una versione meno significativa, con forse correzioni di bug, piccole funzionalità aggiunte o un numero qualsiasi di altri eventi "minori". Ciò potrebbe includere modifiche all'interfaccia e aggiunte. Normalmente le applicazioni dovrebbero essere in qualche modo compatibili nella loro struttura 'major release', quindi le versioni minori della stessa major release dovrebbero essere architettonicamente le stesse.

Numero di build - In genere indica solo correzioni di bug, piccole correzioni e sono piuttosto insignificanti nel loro ambito. Potrebbe essere qualcosa di semplice come cambiare il contrasto tra il primo piano e lo sfondo dell'app. Generalmente, le Build sono designazioni interne come build notturne, quindi hai sempre un posto dove tornare a quello che è stabile.

Numero di revisione - indica quando vengono rilasciate correzioni di errori o vengono apportati MOLTO miglioramenti minori. Questi sono generalmente riservati solo a correzioni di bug - non includere miglioramenti delle funzionalità principali come revisioni.


24
2017-12-28 17:45



Assegniamo a ciascuna build di qualsiasi applicazione un numero di versione a quattro parti univoco definito come Major.Minor.Maintenance.Build.

Maggiore - Il numero maggiore è associato a modifiche significative dell'applicazione. Questo numero determina anche la compatibilità con altre applicazioni nella stessa "suite". Questo numero viene incrementato quando vengono create nuove versioni. Questo di solito significa che sono avvenuti importanti cambiamenti architettonici.

Minore - Il numero Minore è associato a nuove funzionalità e correzioni di errori. Ogni volta che viene introdotta una nuova funzionalità o quando viene applicata una correzione rapida, questo numero verrà avanzato e il numero di manutenzione verrà impostato su zero.

Manutenzione - Il numero di manutenzione è associato a correzioni di bug senza interruzione. Questo numero verrà avanzato ogni volta che viene rilasciata una versione che contiene solo correzioni di errori non di interruzione.

Costruire - Il numero di build è associato al changeset di subversion (numero di revisione) da cui è stata compilata l'applicazione. Ciò fornirà un modo semplice per far corrispondere il numero di versione a un set preciso di codice in sovversione.

L'unico numero che gli sviluppatori sono veramente interessati a questo schema è il Costruire. numero. Legando il Costruire numero al numero di revisione di subversion possiamo garantire quale codice è stato utilizzato per creare l'applicazione rilasciata.


8
2017-12-28 17:52



Penso che il kernel di Linux sia un buon riferimento per questo:

Il numero di versione del kernel di Linux   attualmente consiste di quattro numeri,   dopo un recente cambiamento nel   politica di vecchia data di un numero di tre   schema di controllo delle versioni. Per illustrazione,   si supponga che la versione   il numero è così composto: A.B.C [.D]   (ad esempio, 2.2.1, 2.4.13 o 2.6.12.3).

* The A number denotes the kernel version. It is rarely changed, and

solo quando maggiori cambiamenti nel codice   e il concetto del kernel si verifica.   È stato cambiato due volte nel   storia del kernel: nel 1994   (versione 1.0) e nel 1996 (versione   2.0).

* The B number denotes the major revision of the kernel.
      o Prior to the Linux 2.6.x series, even numbers indicate a stable

rilascio, cioè uno che è ritenuto idoneo   per uso di produzione, come 1.2, 2.4   o 2.6. I numeri dispari hanno storicamente   state versioni di sviluppo, come 1.1   o 2.5. Erano per testare nuovi   caratteristiche e driver fino a quando non sono diventati   sufficientemente stabile da includere in   una versione stabile. Era un pari / dispari   schema del numero di versione.             o A partire dalla serie Linux 2.6.x, non vi è alcun significato per i numeri pari o dispari, con nuovi   sviluppo delle funzionalità in corso nel   stessa serie di kernel. Linus Torvalds ha   ha dichiarato che questo sarà il modello per   il futuro prevedibile.

* The C number indicates the minor revision of the kernel. In the old

schema di versioning a tre numeri, questo   è stato cambiato quando patch di sicurezza, bug   correzioni, nuove funzionalità o driver erano   implementato nel kernel. Con il   nuova politica, tuttavia, è solo   cambiato quando nuovi driver o funzionalità   sono introdotti; le correzioni minori sono   gestito dal numero D.

* A D number first occurred when a grave error, which required immediate

il fixing, è stato rilevato in NFS 2.6.8   codice. Tuttavia, non c'erano abbastanza   altri cambiamenti per legittimare il   rilascio di una nuova revisione minore (che   sarebbe stato 2.6.9). Quindi, 2.6.8.1   è stato rilasciato, con l'unico cambiamento   essere la correzione di quell'errore Con   2.6.11, questo è stato adottato come nuova politica ufficiale di versioning. Bug-fix   e le patch di sicurezza sono ora gestite   dal quarto numero, mentre più grande   le modifiche sono implementate solo in minore   modifiche di revisione (il numero C). Il D   il numero è anche associato al   numero di volte che il compilatore ha   costruito il kernel, e quindi viene chiamato   il "numero di build".

Inoltre, a volte dopo la versione   ci saranno altre lettere simili   come 'rc1' o 'mm2'. Il 'rc' si riferisce a   rilasciare candidato e indica a   versione non ufficiale. Altre lettere   sono di solito (ma non sempre) il   iniziali di una persona. Questo indica a   ramo di sviluppo del kernel di   quella persona. per esempio. ck sta per Con   Kolivas, ac sta per Alan Cox,   mentre mm rappresentava Andrew Morton.   A volte, le lettere sono correlate a   l'area di sviluppo primaria del   il ramo da cui è stato creato il kernel, per   esempio, wl indica un wireless   build test di rete.

A partire dal http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering


6
2017-12-28 17:39



Qualunque sia lo schema di numerazione che scegli, è fondamentale renderlo chiaro ai tuoi utenti quando una nuova versione è compatibile con il vecchio codice client contro quando una nuova versione richiede modifiche ai client esistenti. La maggior parte dei progetti che conosco urta il primo numero quando il codice cliente deve cambiare.

Oltre alla compatibilità, anch'io penso che ci sia molto da dire per l'utilizzo delle date. Anche se diventa imbarazzante se, come me, il tuo programma di rilascio è una volta ogni due anni (ma è per uno strumento pubblicato per la prima volta nel 1989).


3
2017-12-28 18:10



Più probabilmente qualcuno in vendita o marketing deciderà che hanno bisogno di qualche ronzio. Questo determinerà se la prossima versione è 1.01 o 1.1 o 2.0. La stessa cosa funziona allo stesso modo nell'open source, ma tende ad essere legata ad una nuova caratteristica fantasia di cui il team è fiero.


2
2017-12-28 17:38



A.B.C.D

  • A: 0 quando beta, 1 alla prima release, più grande di 1 su quasi intera riscrittura.
  • B: aggiunte nuove funzionalità
  • C: correzioni di bug fatte
  • Il numero di revisione del repository di controllo della versione

2
2017-12-28 17:43



Questo è quello che uso per i moduli nei progetti C incorporati:

1.00 - Versione iniziale

1.01 - Revisione minore
Nessuna modifica di interfaccia al modulo (cioè il file di intestazione non è cambiato). Chiunque utilizzi il mio modulo può eseguire l'aggiornamento senza dover temere di violare il codice. Avrei potuto fare qualche refactoring o pulizia del codice.

2.00 - Revisione importante
L'interfaccia del modulo è cambiata (ad esempio, le funzioni aggiunte, rimosse o la funzionalità di alcune funzioni cambiate). Un aggiornamento a questa revisione probabilmente spezzerà il codice esistente e richiederà il refactoring del codice usando questo modulo.

Dovrei aggiungere che questo si riferisce alla fase di sviluppo, cioè alle versioni interne dei moduli nel progetto.


2
2017-12-28 17:47



Per aggiungere a tutte le spiegazioni di cui sopra, suggerirò di utilizzare uno schema di controllo delle versioni che sarà facile per i tuoi clienti ricordare e facile per te basare e gestire le versioni del tuo software. Inoltre, se stai supportando diversi framework come .Net 1.0, .Net1.1 etc, assicurati che anche il tuo schema di versioning si occupi di questo.


2
2017-12-28 18:27



alcune buone informazioni Qui anche..

Quando cambiare le versioni di file / assieme

Quando cambiare le versioni di file / assieme Prima di tutto, le versioni dei file e le versioni di assemblaggio non devono necessariamente coincidere. Raccomando che le versioni dei file cambino con ogni build. Ma, non modificare le versioni di assembly con ogni build solo in modo da poter distinguere tra due versioni dello stesso file; usa la versione del file per quello. Decidere quando cambiare le versioni di assemblaggio richiede una discussione sui tipi di build da considerare: spedizione e non spedizione.

Build non di spedizione In generale, ti consiglio di mantenere invariate le versioni di assembly non di spedizione tra le versioni di spedizione. Ciò evita problemi di caricamento di assembly con nome elevato a causa di mancate corrispondenze di versione. Alcune persone preferiscono utilizzare la politica dei publisher per reindirizzare le nuove versioni di assembly per ogni build. Vi raccomando tuttavia di non farlo per le versioni non di spedizione: non evita tutti i problemi di caricamento. Ad esempio, se un partner x-copia la tua app, potrebbe non sapere di installare la politica dei publisher. Quindi, la tua app sarà danneggiata, anche se funziona correttamente sul tuo computer.

Ma, se ci sono casi in cui applicazioni diverse sulla stessa macchina devono legarsi a diverse versioni del tuo assembly, ti consiglio di dare a quelle build versioni di assembly differenti in modo che sia possibile utilizzare quella corretta per ogni app senza dover usare LoadFrom / etc.

Costruzioni di spedizione Per quanto riguarda il fatto che sia una buona idea cambiare quella versione per le build di spedizione, dipende da come si desidera che l'associazione funzioni per gli utenti finali. Vuoi che queste build siano side-by-side o sul posto? Ci sono molti cambiamenti tra le due build? Stanno andando a rompere alcuni clienti? Ti interessa che li spezzi (o vuoi forzare gli utenti a usare i tuoi aggiornamenti importanti)? Se sì, dovresti considerare di incrementare la versione dell'assembly. Ma, ripeto, considera che farlo troppe volte può sporcare il disco dell'utente con assiemi obsoleti.

Quando si modificano le versioni di assieme Per cambiare le versioni con hardcoded in quella nuova, ti consiglio di impostare una variabile per la versione in un file di intestazione e sostituire la codifica in codice con la variabile. Quindi, esegui un pre-processore durante la compilazione per inserire la versione corretta. Raccomando di cambiare versione subito dopo la spedizione, non prima, in modo che ci sia più tempo per catturare i bug a causa del cambiamento.


1
2017-12-28 18:14