Quando si utilizza il controllo delle versioni semantico, resta comunque la decisione di stabilire quali modifiche siano considerate "maggiori" e quali siano "minori". Esistono vari motivi per eseguire il bump del numero di versione o per non eseguirne il bump.
I sistemi con le retrocompatibilità potrebbero finire con l'urlare il numero di versione principale con la maggior parte degli aggiornamenti, solo perché c'è una interruzione della compatibilità con le versioni precedenti in alcuni casi angolari più o meno esoterici. Gli stessi sistemi potrebbero rimanere fino a 1.x.y quasi indefinitamente, perché viene fatto un sacco di sforzi per la compatibilità a ritroso, cercando di non rompere mai alcun sistema dipendente. Entrambi gli approcci alla numerazione delle versioni potrebbero essere considerati "conservatori", ma entrambi potrebbero anche essere un segno di un profondo problema di fondo.
Altre volte, in realtà hai una pianificazione del rilascio (pensa ai CD di aggiornamento trimestrali inviati ai clienti), dove ha senso cambiare il numero di versione principale, in modo che invece di "Versione 3.4 / Ott 16 "dice solo" Versione 11.0 ". Al giorno d'oggi, sempre più software viene rilasciato a brevi intervalli, rendendo le pianificazioni di rilascio meno un motivo per attenersi a uno specifico sistema di controllo delle versioni. Ho visto questo nei grandi sistemi di magazzino che consentono all'IT interno solo un giorno di downtime su un quarto (di solito una domenica). Questo giorno è il giorno della distribuzione ed è contrassegnato ogni volta con una nuova versione principale.
Alcuni programmi hanno dipendenze esterne che sono della massima importanza, poiché l'utente dovrà aggiornarli entrambi allo stesso tempo. Se si dispone di un componente aggiuntivo di Word che funziona solo con Word 2010 e un altro per Word 2013, è possibile che si desideri sincronizzare i numeri di versione principali con quelli di MS-Word. Qui, i numeri importanti sono così importanti, perché alcuni dei tuoi utenti saranno "indietro" rispetto alla normale pianificazione degli aggiornamenti, dal momento che non sono stati aggiornati alla versione più recente di Word (o qualsiasi altra cosa su cui ti basi: SAP, Dynamics, ecc).
A volte, altri fattori esterni dettano i numeri di versione. Se si dispone di software fiscale, potrebbero esserci aggiornamenti annuali corrispondenti alla legislazione fiscale (che tende ad entrare in vigore il 1 ° gennaio). Tali sistemi avranno le versioni principali che cambiano esattamente una volta all'anno - non perché questo è il programma di aggiornamento, ma perché questo è di altra importanza per il cliente: se si fanno le tasse del 2016, è meglio avere un programma aggiornato alla legge fiscale del 2016.
Alla fine, i numeri di versione dipendono da tanti fattori - spesso specifici per un dominio - che il numero da solo non ti dice nulla sullo stato della tua base di codice. È un approccio molto migliore da guardare quando, perché e come avvengono gli schieramenti, e con che facilità. Se riesci a implementare un importante aggiornamento a 10.000 clienti e fare un paio di telefonate, probabilmente stai bene. Se si distribuisce una patch minore a 10 clienti e si deve lavorare straordinariamente a causa di ciò, qualcosa è probabilmente sbagliato.