Quando cambi il numero di versione major / minor / patch?

Dopo aver rilasciato il software, il numero di versione dovrebbe essere incrementato immediatamente.

Perché?

Supponiamo che tu stia seguendo uno schema come Semantic Versioning , e nella versione hai un numero di build. Quindi potresti avere [Major]. [Minor]. [Patch]. [Build]. Chiamerò il [Major]. [Minor]. [Patch] parte la versione.

Creerai più build durante lo sviluppo. Ogni build è un'istantanea di sviluppo della tua prossima versione. Ha senso usare la stessa versione per le build di sviluppo e rilascio. La versione indica che versione stai lavorando verso .

Se ti stai preparando per il rilascio e il software passa tutti i test, non vorrai ricostruire e ritestare il software solo perché hai dovuto aggiornare la versione. Quando alla fine si rilascia una versione, si afferma che "build 1.1.0.23" verrà d'ora in poi definito "versione 1.1.0".

Il modello incrementa dopo il rilascio ha un senso anche per la ramificazione. Supponiamo di avere un ramo di sviluppo principale e di creare rami di manutenzione per le versioni. Nel momento in cui crei il tuo ramo di rilascio, il tuo ramo di sviluppo non è più collegato al numero di versione di quel rilascio. Il ramo di sviluppo contiene il codice che fa parte della prossima versione, quindi la versione dovrebbe rispecchiarlo.

In genere cerco di utilizzare SemVer per i numeri di versione interni. È bello poter sapere qualcosa su una versione basata sulla semantica del suo numero di versione.

Durante lo sviluppo, cerco di modificare immediatamente i numeri di versione (se possibile) . A volte è difficile sapere se il cambiamento cambierà o meno (il che influenzerà il mio numero di versione), quindi niente è "fissato nella pietra".

Per indirizzare il tuo esempio specifico:

• Durante lo sviluppo, le versioni pre-release sarebbero 1.0.1-alpha.1, 1.0.1-alpha.2, ecc.
• La versione finale della correzione di bug sarebbe la versione 1.0.1.

Detto questo, i numeri di versione del prodotto "rivolti al pubblico" sono spesso impostati dal marketing e sono completamente diversi. Questo è fuori dal mio controllo, quindi non c'è motivo di preoccuparsene.

In grandi progetti / organizzazioni, i numeri di versione maggiore e minore sono controllati dai dipartimenti di marketing e in genere vengono incrementati per ragioni di marketing. Alla mia organizzazione, i gruppi mirano a rilasciare una versione maggiore e una minore ogni anno. L'aspettativa è che le versioni principali contengano nuove funzionalità significative e che vi sia compatibilità binaria tra le API per tutte le versioni con lo stesso numero di versione principale. Tuttavia, il marketing può scegliere di eseguire il downgrade di una modifica di versione maggiore a quella secondaria perché le funzionalità promesse non vengono fornite o viceversa per essere viste, ad esempio, per saltare la competizione di rana.

I numeri di serie maggiori e minori (c e d in a.b.c.d) sono generalmente controllati dallo sviluppo. c è il numero di build e d è usato per le patch su una particolare release o versione di c.

Nel tuo caso, quando cambi i numeri di versione maggiore e minore è meno importante che assicurarsi che i numeri di serie maggiori e minori siano accurati. Nella mia organizzazione, modifichiamo i numeri di serie maggiori e minori come parte del processo di ramificazione nel controllo del codice sorgente. Il ramo principale di solito contiene l'ultima versione ma il marketing potrebbe non aver deciso quale numero di versione avrà ancora.

Let's assume A.B.C.D in the answers. When do you increase each of the components?

Fondamentalmente è determinato dalla tua politica aziendale. La nostra politica aziendale è:

• A - Cambiamenti significativi (> 25%) o aggiunte in funzionalità o interfaccia.
• B - piccole modifiche o aggiunte in funzionalità o interfaccia.
• C - lievi modifiche che rompere l'interfaccia.
• D - risolve in a costruire che non cambia il interfaccia.

Proviamo e seguiamo l'esempio Eclipse . Fa un lavoro di spiegazione migliore di quello che posso, ma effettivamente per noi funziona così:

Quando si rilascia 1.0.0.0, il numero di versione che si modifica dipende dal tipo di modifica che si sta apportando.

• Una versione che non influisce sull'API, prendi in considerazione una correzione del bug dietro le quinte che rende l'API corrente funzionante nel modo previsto, è rilasciata alla 1.0.1
• Una versione che si aggiunge all'API ma non modifica l'API esistente, è possibile che sia stata aggiunta una nuova funzionalità che non rende gli attuali client incomparabili con la nuova versione. Questo può includere qualsiasi numero delle correzioni di cui sopra pure.
• Una versione interrompe l'API corrente, rimuovendo qualcosa, modificando qualcosa nel modo in cui rompe la comparabilità con i client correnti. Questo può avere qualsiasi ombra delle correzioni di cui sopra pure.

Per quanto riguarda l'uso della 4a sezione nel numero di versione, usiamo questo per differenziare le diverse build in Nuget (la soluzione di gestione dei pacchetti che usiamo per .net). Questo ci consente di evitare di dover cancellare le cache ogni volta che è necessario aggiornare il nostro software non rilasciato.

Non esiste una prossima build. Su quel ramo.

Versione idealizzata del nostro schema.

L'identificazione della versione su qualsiasi ramo è PRETTY_BRANCH_NAME-build e PRETTY_BRANCH_NAME è corretto alla creazione del ramo.

Il nostro schema di ramificazione (*) è il seguente:

I rami di primo livello, il PRETTY_BRANCH_NAME di ciascuno è un nome in codice, che parla del numero di versione a quel livello è privo di significato, potrebbe esserci uno schema pianificato ma cambierà prima del rilascio.

• un ramo TNG ( la prossima generazione ) in cui viene realizzato lo sviluppo a lungo termine. Spesso non ce l'abbiamo nemmeno e non ha mai (rilasciato) subbranches.

• un ramo TCG ( la generazione corrente ) in cui viene eseguito lo sviluppo corrente. PRETTY_BRANCH_NAME è un nome in codice.

• un ramo TPG ( la generazione precedente ). Spesso non si fa più lo sviluppo qui, ma ci possono essere attività nei subbranches.

Un subbranch è costituito da un ramo di livello superiore (di TCG, in presenza di una migrazione lenta di TPG) quando la versione beta di un major release inizia. Il PRETTY_BRANCH_NAME è qualcosa come "1.3.X" (X è la lettera, non la cifra, significa che intendiamo consegnare 1.3 versioni da qui), il feedback dalla beta è token in considerazione qui mentre il lavoro per la prossima major release è fatto su il ramo TCG.

Idealmente, la release dovrebbe essere un'istantanea su quel ramo, ma sappiamo che non siamo perfetti e spesso abbiamo bisogno di fare cambiamenti dell'ultimo minuto, consentendo agli altri di continuare a lavorare per la prossima versione secondaria. Così i subwoofer sono fatti per la stabilizzazione finale con i nomi carini come numero di versione ufficiale (a quel tempo anche il marketing non vorrebbe cambiarlo) come "1.3", "1.3.1" dal ramo "1.3.X", l'ultima build su ciascuna è la versione.

Se avessimo un quarto livello, i nomi dei sottoprogrammi sarebbero stati "1.3.0.X" dai quali avremmo avuto sub ^ 3branches "1.3.0.0" "1.3.0.1".

(*) Al livello di rilascio. Ci possono essere sottoprogetti di progetto su ciascuno di questi.

Se vendi software, avrai una nuova major release ogni volta che le vendite / marketing necessitano di guadagnare un bonus più grande: -)

Se hai qualche controllo allora: -

Principali versioni quando: -

• C'è qualche incompatibilità con la versione precedente che richiede la conversione, ecc. Pensa Pyhton 2 ... a Python 3 ...

• L'intero pacchetto di nuove funzionalità

  Realizzazioni minori per qualsiasi piccola funzionalità di cange, rilascio di patch per correzioni di bug.