Quando cambiate il numero di versione maggiore / minore / patch?

Possibile duplicato:
quale "convenzione di denominazione della versione" usi?

Modifichi i numeri di versione maggiore / minore / patch subito prima del rilascio o subito dopo?

Esempio: hai appena rilasciato 1.0.0 al mondo (huzzah!). Ma aspetta, non festeggiare troppo. 1.1.0 uscirà tra sei settimane! Quindi correggi un bug e fai una nuova build. Come si chiama quella build? 1.1.0.0 o 1.0.0.xxxy (dove xxxy è il numero di build di 1.0.0 incrementato)?

Tieni presente che potresti avere 100 funzionalità e bug per andare in 1.1.0. Quindi potrebbe essere utile chiamarlo 1.0.0.xxxy, perché non sei vicino alla 1.1.0. D'altra parte, un altro sviluppatore potrebbe funzionare su 2.0.0, nel qual caso la tua build potrebbe essere meglio denominata 1.1.0.0 e la sua 2.0.0.0 invece di 1.0.0.xxxy e 1.0.0.xxxz, rispettivamente.

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

Perché?

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

Durante lo sviluppo creerai più build. Ogni build è un'istantanea di sviluppo della prossima versione. Ha senso usare la stessa versione per lo sviluppo e le build di rilascio. La versione indica quale rilascerà si sta lavorando verso .

Se ti stai preparando per il rilascio e il software supera tutti i suoi test, non vorrai ricostruire e ripetere il test del software solo perché hai dovuto aggiornare la versione. Quando alla fine rilasci una versione, stai dichiarando che "build 1.1.0.23" sarà d'ora in poi definita "versione 1.1.0".

Il modello increment-after-release ha senso anche per le ramificazioni. Supponiamo di avere un ramo di sviluppo principale e di creare rami di manutenzione per le versioni. Nel momento in cui crei il ramo di rilascio, il ramo di sviluppo non è più collegato al numero di versione di quel rilascio. Il ramo di sviluppo contiene codice che fa parte della prossima versione, quindi la versione dovrebbe riflettere questo.

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

Durante lo sviluppo, provo a cambiare subito i numeri di versione (se possibile) . A volte è difficile sapere se la modifica sarà o meno una modifica (che influenzerà il mio numero di versione), quindi nulla è "impostato sulla pietra".

Per rispondere al 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 "pubblico" sono spesso impostati dal marketing e sono completamente diversi. Questo è fuori dal mio controllo, quindi non c'è motivo di preoccuparsene.

Assumiamo ABCD nelle risposte. Quando aumenti ciascuno dei componenti?

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

• A - Modifiche (> 25%) significative o aggiunte nella funzionalità o nell'interfaccia.
• B - piccole modifiche o aggiunte nella funzionalità o nell'interfaccia.
• C - modifiche minori che interrompono l'interfaccia.
• D - risolto un build che non cambia l'interfaccia.

Nei progetti / organizzazioni più grandi, i numeri di versione principali e secondari sono controllati dai dipartimenti di marketing e di solito vengono incrementati per motivi di marketing. Nella mia organizzazione, i gruppi mirano a rilasciare una versione principale e una versione 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 della versione principale a secondaria perché le funzionalità promesse non vengono consegnate o viceversa, ad esempio, per saltare la concorrenza delle rane.

I numeri di build maggiori e minori (c e d in abcd) sono generalmente controllati dallo sviluppo. c è il numero di build e d viene utilizzato per le patch su una versione o una versione particolare di c.

Nel tuo caso, quando modifichi i numeri di versione maggiore e minore è meno rilevante che garantire che i numeri di costruzione maggiore e minore siano precisi. Nella mia organizzazione, cambiamo i numeri di build principali e secondari come parte del processo di diramazione nel controllo del codice sorgente. Il ramo principale di solito contiene l'ultima versione, ma è possibile che il marketing non abbia deciso quale numero di versione avrà ancora la versione.

Proviamo a seguire l' esempio di Eclipse . Fa un lavoro di spiegazione migliore di quello che posso, ma efficacemente per noi funziona così:

Quando si rilascia 1.0.0.0 il numero di versione in cui si cambia dipende dal tipo di modifica che si sta effettuando.

• Una versione che non ha effetto sull'API, considera una correzione di bug dietro le quinte che fa funzionare l'API corrente 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 i client attuali incomparabili con la nuova versione. Questo può includere anche qualsiasi numero delle correzioni sopra.
• Una versione interrompe l'API corrente, rimuovendo qualcosa, cambiando qualcosa nel modo che interrompe la comparabilità con i client attuali. Questo può avere anche qualsiasi ombra delle correzioni di cui sopra.

Per quanto riguarda come utilizzare la quarta sezione del numero di versione, la utilizziamo per differenziare diverse build in Nuget (la soluzione di gestione dei pacchetti che utilizziamo per .net). Questo ci consente di evitare di dover cancellare le cache ogni volta che è necessario aggiornare il nostro software inedito.

Non esiste una build successiva. Su quel ramo.

Versione idealizzata del nostro schema.

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

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

Filiali di primo livello, il PRETTY_BRANCH_NAME di ciascuno è un nome in codice, parlando del numero di versione a quel livello non ha senso, potrebbe esserci uno schema pianificato ma cambierà prima del rilascio.

• una filiale di TNG ( la prossima generazione ) in cui viene realizzato uno sviluppo a lungo termine. Spesso non ce l'abbiamo nemmeno e non ha mai (rilasciato) sottogruppi.

• un ramo TCG ( l'attuale generazione ) in cui viene realizzato lo sviluppo attuale. PRETTY_BRANCH_NAME è un nome in codice.

• un ramo TPG ( la generazione precedente ). Spesso qui non viene fatto altro sviluppo, ma potrebbero esserci attività nei sottogruppi.

Un subbranch è costituito da un ramo di livello superiore (di TCG, in presenza di una migrazione lenta di TPG) quando inizia la beta per un rilascio importante. PRETTY_BRANCH_NAME è qualcosa come "1.3.X" (X è la lettera, non la cifra, significa che intendiamo fornire le versioni 1.3 da qui), il feedback dalla beta viene preso in considerazione qui mentre il lavoro per la prossima versione principale viene svolto su la filiale TCG.

Idealmente, il rilascio 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 il prossimo rilascio minore. Quindi i sub-marchi sono creati per la stabilizzazione finale con nomi graziosi come il numero di versione ufficiale (a quel tempo anche il marketing non vorrà 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 sottosubri sarebbero stati "1.3.0.X" dai quali avremmo avuto i sottosettori 3 "1.3.0.0" "1.3.0.1".

(*) A livello di rilascio. Ci possono essere sotto-progetti su ciascuno di questi.

Se vendi software, avrai una nuova versione importante ogni volta che le vendite / marketing devono guadagnare un bonus più grande :-).

Se hai qualche controllo, allora:

1. Principali rilasci quando:

   • C'è una certa incompatibilità con la versione precedente che richiede la conversione ecc. Come da Python 2 a Python 3.

   • C'è un intero pezzo di nuove funzionalità.

2. Rilasci minori per eventuali piccoli cambiamenti nella funzionalità.

3. Rilascio patch per correzioni di errori.