Bump versione prima di dare il via al nuovo sviluppo o al tagging di una release, che è meglio?

Naviga le tue risposte
9

Alcuni progetti eseguono il bump della versione prima di dare il via a un nuovo sviluppo, mentre gli altri progetti eseguono il bump della versione durante il tagging di un rilascio.

Quale approccio è migliore?

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

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

git describe può darti v1.2.3.4-15-g1234567 se la revisione corrente è successiva alla v1.2.3.4, ma hai già cambiato i file per avere v1.2.3.5

    
posta linquize 03.11.2012 - 03:32
fonte

2 risposte

2

Il motivo principale per il numero di versione è lì in modo che quando viene scoperto un bug, puoi eseguire il debug usando la versione effettiva del codice sorgente in cui si è verificato l'errore (quindi scopri la vera ragione del bug).

Non importa quale schema di versioning usi finché l'utente del tuo prodotto può comunicare allo sviluppatore abbastanza informazioni in modo che lo sviluppatore possa raggiungere questo obiettivo.

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

  • Aiuto
    Vuole un modo semplice per determinare la compatibilità e le caratteristiche e potenzialmente la stabilità (vedi lo schema dei numeri pari / dispari di Linux).
  • Marketing
    Vuole un numero maggiore ogni volta (preferibilmente superiore a 2)

  • legale Vuole essere certo di avere tutte le funzioni impegnate prima di aumentare il numero.

In tutti i casi lo schema utilizzato non è importante. Finché sei coerente (o hai facilmente disponibile una documentazione altamente dettagliata sui cambiamenti di significato).

    
risposta data 03.11.2012 - 14:19
fonte
1

Quando si utilizzano numeri di versione a quattro segmenti come gli assembly .NET, preferisco usare un tag di controllo della 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-describe restituisce "v1.2.3-4-g1a2b3c4", allora quando viene generato quell'assembly viene sottoposto a versioning come 1.2.3.4.

Se un tag viene successivamente applicato a quella versione, git-describe restituirà 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 resa ".0" semplicemente taggandola.
  • Sebbene non perfetto, questo sistema funziona con DVCS perché conta il numero di commit dal tag più recente.
risposta data 03.11.2012 - 06:04
fonte

Leggi altre domande sui tag

IPC senza blocco in Linux per processori multi-core In che modo le licenze CC (0, BY, BY-SA) influenzano le applicazioni proprietarie / closed source?