Il n’y a pas qu’une seule règle de versionnage sémantique. Un versionnage sémantique, c’est toute règle de versionnage où le numéro de version n’est pas déterminé arbitrairement, mais selon des règles qui définissent le numéro d’une version en fonction du numéro d’une précédente version et de la nature des changements effectués depuis.
D’ailleurs, la règle la plus classique de versionnage sémantique, celle qui a littéralement été nommée « gestion sémantique de version », ce n’est pas celle que tu décris. Il n’y a pas de notion de modification majeur/modification mineure (ce qui au passage est relativement arbitraire hein… une réécriture complète sans aucun changement fonctionnel, c’est majeur pour le développeur, mineur pour l’utilisateur par exemple…), mais simplement une notion de rupture ou non de la compatibilité avec la version précédente : Gestion sémantique de version 2.0.0 | Semantic Versioning
Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter :
1. le numéro de version MAJEUR quand il y a des changements non rétrocompatibles,
2. le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles,
3. le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétrocompatibles.
Si tu prends un navigateur par exemple (mais le semver se prête en fait assez peu à des logiciels complets, c’est plus adapté à des bibliothèques), il suffit de faire une modification mineure non rétrocompatible, par exemple supprimer le support de la balise HTML marquee, pour que le semver t’impose d’incrémenter le numéro de version majeure.
À l’inverse, si tu as un simple viewer de HTML, tu peux le faire évoluer vers une suite Internet complète façon feu Mozilla SeaMonkey, tant que ça sait toujours visualiser un fichier HTML comme la version de base, tu n’incrémentes que le numéro de version mineur.
Et tu peux même faire une réécriture intégrale du logiciel, en ne conservant pas une seule ligne de code originale, si tu n’as ni ajouté ni retiré de fonctionnalité, tu ne changes que le numéro de correctif…
Un autre exemple de versionnage sémantique classique, c’est celui de libtool, très utilisé pour le versionnage des interfaces de bibliothèques dans le monde Linux, et là encore, pas de notion de changement majeur/mineur, la philosophie est la même qu’en semver, permettre d’après le numéro de version de savoir s’il y a rupture de compatibilité ou pas, mais avec une approche différente, les mises à jour « correctives » ne touchent qu’au deuxième nombre, les mises à jour rétrocompatibles incrémentent le premier ET le troisième (qui est appelé « age », est en fait le nombre d’évolutions fonctionnelles qu’il y a eu depuis la dernière rupture de compatibilité), les mises à jour non rétrocompatibles incrémentent le premier et mettent le troisième à zéro… donc par exemple, si en partant de la 2:0:0 tu ajoutes une fonction et en supprime une, tu passes en 3:0:0, mas par contre si tu fait seulement un ajout tu passes de 2:0:0 à 3:0:1).
Quand à la numérotation des versions de Firefox, c’est bel et bien aussi une forme de numérotation sémantique, puisqu’il y a bien une règle stable pour déterminer quel nombre incrémenter à chaque release, ce n’est pas fait de façon « arbitraire » :
- incrémentation du premier nombre pour les mises à jour fonctionnelles de la version standard,
- incrémentation du second nombre pour les mises à jour fonctionnelles dans le canal ESR (moment où la version ESR diverge du coup de la version standard, alors que tant que le second nombre est à 0, standard et ESR ont le même code),
- incrémentation du troisième nombre pour les mises à jour correctives.
(et en fait, comme il y a de bonnes chances que chaque version de Firefox casse au moins sur un point la compatibilité avec la version précédente, le versionnage de Firefox respecte sans doute quasiment toujours les règles de semver)
En exemple de numérotation qui n’est pas sémantique, je citerai plutôt les très classiques versionnages basés sur la date (par exemple, les versions d’Ubuntu, qui sont en YY.MM), ou encore les plus originaux versionnages utilisés par Donald Knuth pour TeX et Metafont : le numéro de version est pi ou e avec une décimale de plus à chaque version. Là il n’y a effectivement aucune sémantique, on n’a aucune information sur la nature de la mise à jour dans le numéro de version.
Et non, ils ne sont pas « censés » avoir une version 99.1.0 entre la 99.0.0 et la 100.0.0. Au contraire, les règles de numérotation de Firefox imposent même qu’il n’y ait PAS de 99.1 entre la 99.0 et la 100.0, puisque le deuxième nombre est réservé aux ESR (et une ESR x.1 n’est pas entre la x.0 et la x+1.0, elle est entre la ESR x.0 et la ESR z.0 avec z >> x + 1).
Et d’ailleurs, même en semver ou en libtool, il n’y a jamais de telle obligation… Parce que justement, à partir du moment où tu as une numérotation sémantique, tu ne peux pas imposer d’avoir un certain numéro de version à un moment donné : c’est la nature des modifications qui impose le numéro de version, et tu n’as pas forcément fait de modifications qui mènent à un numéro donné… Par exemple en semver, si après ta version 99.0.0 tu fais une version qui casse la compatibilité, tu DOIS passer en 100.0.0, y a aucune obligation d’avoir eu une 99.1.0 entre temps…
Seul une système de numérotation non sémantique peut t’imposer l’existence de certains numéro de version. Par exemple, la numérotation de TeX, oui, elle impose des numéros de version, tu peux pas sortir une 3.1415 après une 3.14, tu dois impérativement avoir fait une 3.141 entre les deux.
