Lors de l'utilisation du contrôle de version sémantique, il reste à décider quels changements sont considérés comme "majeurs" et lesquels sont "mineurs". Il existe plusieurs raisons de bump le numéro de version - ou de ne pas le bump.
Les systèmes avec des promesses de compatibilité descendante pourraient finir par augmenter le numéro de version principal avec la plupart des mises à jour, simplement parce qu'il y a une rupture de compatibilité descendante dans certains cas d'angle plus ou moins ésotériques. Les mêmes systèmes pourraient rester presque indéfiniment dans 1.xy, car beaucoup d'efforts sont consacrés à la compatibilité descendante, en essayant de ne jamais casser aucun système dépendant. Les deux approches de la numérotation des versions pourraient être considérées comme «conservatrices», mais les deux pourraient également être le signe d'un profond problème sous-jacent.
D'autres fois, vous avez en fait un calendrier de sortie (pensez aux CD de mise à jour trimestriels envoyés aux clients) où il est logique de changer le numéro de version principal, de sorte qu'au lieu de "Version 3.4 / 16 octobre", il est simplement dit "Version 11.0". De nos jours, de plus en plus de logiciels sont publiés à de courts intervalles, ce qui rend les calendriers de publication moins une raison de s'en tenir à un schéma de version spécifique. J'ai vu cela dans les grands systèmes d'entrepôt qui n'autorisent l'informatique interne qu'un jour d'indisponibilité par trimestre (généralement un dimanche). Ce jour est le jour du déploiement et est marqué à chaque fois par une nouvelle version majeure.
Certains programmes ont des dépendances externes qui sont de la plus haute importance, car l'utilisateur devra mettre à jour les deux en même temps. Si vous disposez d'un module complémentaire Word qui ne fonctionne qu'avec Word 2010 et un autre pour Word 2013, vous souhaiterez peut-être synchroniser vos numéros de version principaux avec ceux de MS-Word. Ici, les nombres majeurs sont si importants, car certains de vos utilisateurs seront "derrière" votre calendrier de mise à jour normal, car ils n'ont pas mis à jour vers la version la plus récente de Word (ou quoi que ce soit sur lequel vous vous appuyez: SAP, Dynamics, etc).
Parfois, d' autres facteurs externes dictent les numéros de version. Si vous avez un logiciel fiscal, il peut y avoir des mises à jour annuelles correspondant à la loi fiscale (qui a tendance à entrer en vigueur le 1er janvier). De tels systèmes auront des versions majeures changeant exactement une fois par an - non pas parce que c'est le calendrier de mise à jour, mais parce que cela est d'une autre importance pour le client: Si vous faites vos taxes 2016, vous feriez mieux d'avoir un programme mis à jour selon la loi fiscale 2016.
En fin de compte, les numéros de version dépendent de tant de facteurs - souvent spécifiques à un domaine - que le numéro seul ne vous dit rien sur l'état de votre base de code. C'est une bien meilleure approche pour voir quand, pourquoi et comment les déploiements se produisent - et comment cela se passe sans heurts. Si vous pouvez déployer une mise à jour majeure auprès de 10 000 clients et passer quelques appels téléphoniques, tout va bien. Si vous déployez un correctif mineur pour 10 clients et devez faire des heures supplémentaires à cause de cela, quelque chose ne va probablement pas.