Alcuni strumenti impongono agli sviluppatori di adottare uno schema di versione di un certo modulo, forma l'istanza "major.minor.build.revision", in cui ogni campo deve essere un numero.
Come posso inserirmi in beta? Ad esempio, quale versione dovrei scegliere per la versione "2.0 beta2"? Dovrebbe essere nella forma "1.99.x.y" (non è ancora 2.0 stabile) o "2.0.x.y" (la versione beta 2.0 introduce modifiche di rottura con 1.x).
Se sei bloccato con revisioni puramente numeriche potresti fare delle revisioni minori dispari rilasciare beta per il maggiore corrispondente che ha un numero pari minore, per esempio
Beta : 1.3.11.df41a
Rilascia : 1.4.1.df41a
La beta per 2.0 potrebbe quindi essere una qualsiasi di 1.9, 1.11, ...
nell'esempio di "major.minor.build.revision" abbiamo abbandonato il numero di revisione e usato l'ultimo per indicare una beta (dove beta significherebbe "non completamente testato"):
1.2.1.0 -> normal release
1.2.1.1 -> beta release
Ora ti sento dire "quale numero di revisione? come si rintracciano i bug", come so che le persone / aziende a volte tendono ad abbinare il numero di "revisione" con il loro VCS specialmente quando si usa svn. Almeno due opzioni: eliminare il numero di build e mantenere la revisione (hai veramente bisogno di più di major.minor per la versione attuale?), O quello che facciamo è taggare il repository con il numero di versione per ogni release che è il contrario, ma ha lo stesso effetto + riteniamo che i client non debbano sapere quale sia la quantità di commit in un VCS.
Potresti modificare la pratica di Major.Minor.Build.Revision in qualcosa di più simile a Major.Minor.Release.Revision. Vedi esempi:
1.0.0.0 - First Release
1.0.0.123 - Beta build approaching second release
1.0.1.0 - Next release
1.0.1.234 - Beta build approaching third release
1.1.0.0 - Third release
etc ..
Leggi altre domande sui tag versioning beta