Versione Bump prima di dare il via al nuovo sviluppo o quando si tagga una versione, che è meglio?

Alcuni progetti eseguono il bump della versione prima di dare il via a un nuovo sviluppo, mentre altri progetti eseguono il bump della versione quando si contrassegna una versione.

Quale approccio è migliore?

Se il numero di versione non viene modificato all'inizio di una nuova fase, gli sviluppatori potrebbero dimenticare di cambiarlo e semplicemente rilasciare il programma.

Se il numero di versione è cambiato prima del rilascio della codifica, 2 i numeri di versione (tag e Makefile / AssemblyInfo.cs) non corrispondono.

git describe potrebbe darti v1.2.3.4-15-g1234567 se la revisione corrente è successiva a v1.2.3.4, ma hai già modificato i file per avere v1.2.3.5

Il motivo principale per il numero di versione è lì in modo che quando viene scoperto un bug è possibile eseguire il debug utilizzando la versione effettiva del codice sorgente in cui si è effettivamente verificato l'errore (quindi scoprire il vero motivo del bug).

Non importa quale schema di controllo delle versioni usi purché l'utente dei tuoi prodotti possa comunicare allo sviluppatore informazioni sufficienti affinché lo sviluppatore possa raggiungere questo obiettivo.

Altre ragioni per il versioning sono per i team di marketing e di aiuto (a volte legali).
Queste squadre hanno le proprie priorità per il controllo delle versioni.

• Aiuto
  Vuole un modo semplice per determinare la compatibilità, le caratteristiche e la potenziale stabilità (vedi schema dei numeri pari / dispari di Linux).
• Il marketing
  vuole ogni volta un numero maggiore (preferibilmente superiore a 2)
• Legale
  Vuole assicurarsi di avere tutte le funzionalità impegnate prima di aumentare il numero.

In tutti i casi lo schema utilizzato non è importante. Fintanto che si è coerenti (o si dispone di una documentazione altamente dettagliata facilmente disponibile sui cambiamenti di significato).

Quando si usano numeri di versione a quattro segmenti come negli assembly .NET, preferisco usare un tag di controllo versione per impostare i primi tre segmenti, quindi il quarto segmento è il numero di commit da quel tag.

Ad esempio, una versione viene taggata "v1.2.3". Se git-describerestituisce "v1.2.3-4-g1a2b3c4", quando viene creato quell'assieme viene aggiornato come 1.2.3.4.

Se un tag viene successivamente applicato a quella versione, git-describerestituirà invece "v1.2.4", che rappresenta la versione 1.2.4.0. Il prossimo commit sarebbe quindi 1.2.4.1.

I vantaggi che trovo da questo sistema sono:

• Ogni commit incrementa automaticamente il numero di versione.
• Una versione può essere rilasciata ".0" semplicemente tag.
• Sebbene non sia perfetto, questo sistema funziona con DVCS perché conta il numero di commit dall'ultimo tag.