Après Chrome, l’heure est venue pour Firefox de passer la symbolique barre de la version 100. Il n’y a pas de révolution à trouver sous le capot, mais quelques nouveautés sont malgré tout les bienvenues.
1 « J'aime »
Un peu déçu par si peu de nouveautés pour un 100ème version…
3 « J'aime »
Effectivement, un peu léger la mise à jour…
C’est le principe avec les nouvelles versions à intervalle fixe, y a pas vraiment de version plus importante qu’une autre, même si y a un numéro rond, les nouveautés arrivent à mesure qu’elles sont disponibles.
5 « J'aime »
Google et Firefox ne respectent plus le versionnage sémantique depuis qu’ils sont en guerre.
Première chose qu’on nous apprend en cours de développeur :
version 12.345.678
- Le 1er groupe de chiffre c’est une modification majeure.
- 2e groupe, une modif mineure.
- 3e groupe, debug.
Ils sont censé avoir une version 99.1.0 avant de passer à la version 100.
3 « J'aime »
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.
3 « J'aime »
Si le versionning n’avait pas perdu la tête avec un tel chiffre on serait en 2055…
edge est aussi en version 100 et même 101 depuis, c’est plus vraiment une info ?
c’est vraiment nul ces version qui veulent rien dire!
c’est celui qui a plus grosse, c’est moche.
par contre, qql1 sait me dire comment virer ces p**** de PiP sous Android ?
ça me saoule c’est vidéo qui prennent la place de l’article à lire!!!
2 « J'aime »
Parce que si le numéro était plus petit, ça voudrait plus dire quelque chose ?
C’est quoi un numéro de version « qui veut dire quelque chose » ?
Le principal rôle du numéro de version pour l’utilisateur final, c’est de permettre de savoir si on a la dernière version. La numérotation de Firefox permet de le savoir.
En rôles secondaires, c’est utile pour le support quand on lui remonte un bug, pour qu’ils puissent tester avec la même version. Là encore, la numérotation de Firefox permet de le savoir.
Que demander de plus ?
1 « J'aime »
Il y a vraiment des gens qui râlent à cause du numéro de version de Firefox ??? Il en faut bien peu pour certains dis-donc …
2 « J'aime »
Je suis assez d’accord sur le fait qu’avoir des numéros de version plus en lien avec des sauts technologiques ou l’arrivée de fonctionnalités était plus clair qu’une incrémentation en rolling release comme actuellement.
On peut avoir 5 versions avec ajustements cosmétiques et puis une où les perfs sont améliorées de 30% avec changement de moteur derrière super impactante et la numérotation reste la même?
Pour des petits projets agiles numéroter en fonction de la date des devs pourquoi pas, pour du progiciel de référence c’est assez pourri comme pratique il faut le dire.
Genre les millions de gens dans le monde chargés de maintenir en état de fonctionnement des applicatifs dont la couche de présentation repose sur les navigateurs et qui s’engagent contractuellement à un fonctionnement de l’appli fonction de la version du navigateur ?
Concrètement, pour l’utilisateur, ça change quoi ?
Surtout que dans le domaine des navigateurs, on peut quasiment considérer aujourd’hui que toutes les mises à jour sont majeures, car il y a quasiment toujours au passage des correctifs de sécurité… Et là, avoir seulement un 2ème ou 3ème numéro qui change, ça peut pousser l’utilisateur à ce dire « bof, cette mise à jour est pas importante, j’attends la suivante… ». Alors qu’en fait non, elle EST importante.
Ben eux au contraire, ça les arrange, ça les libère de leur engagement contractuel…
Parce que si par exemple dans la dernière version de Firefox (donc la 100), il y a un changement qui casse la compatibilité avec une application web, ceux qui étaient engagés contractuellement à être compatibles avec Firefox 99, ben il y a pas de souci, comme c’est plus Firefox 99 ils ne sont pas responsable de la rupture de compatibilité (ce qui dans les fait est la réalité !) et peuvent donc facturer le correctif.
Alors que si Mozilla l’avait numéroté 99.1 au lieu de 100.0, ceux qui étaient engagés à être compatibles Firefox 99 devraient faire la correction…
De toute façon, fondamentalement, c’est une erreur de prendre un engagement contractuel sur un truc que tu ne maitrise pas… Or le fait qu’une future version du navigateur casse la compatibilité avec une appli web, c’est quelque chose que le développeur de l’appli ne maitrise pas, et que ça soit une x.y.z+1, une x.y+1.0 ou une x+1.0.0 du navigateur n’y change rien… Donc si tu t’engages contractuellement sur une version, tu vas jusqu’au bout, tu met le numéro de version complet dans l’engagement, pas juste le numéro majeur…
1 « J'aime »
oui mais c’est quand même nul 
merci pour les explications
par contre, ils ne sont même pas sensés être à la version 99 ou 100
ces numéros de versions qui défilent c’est du délire.
c’est comme si on disait qu’on est sous windows 247.8 xD
Non, c’est simplement le principe d’un développement en mode agile, avec des livraisons très fréquentes.
Oui, et ? Ce serait si gênant que ça ?
Microsoft a simplement fait un choix différent dans ses numérotations et de ne pas changer souvent les deux premiers nombres, mais en pratique ça changerait rien que tu sois sous Windows 247.8 ou Windows 10…
Par exemple, depuis qu’il sont passés à deux livraisons par an, ils auraient très bien pu décider d’incrémenter le numéro majeur tous les 6 mois, ça ne changerait rien pour nous et ça serait tout aussi valable que ce qu’ils font actuellement, ie incrémenter un numéro de build qui n’a pas plus de sens que le numéro majeur, et qui est même devenu complètement arbitraire, ce n’est plus un « vrai » numéro de build (sur les 10 dernières versions de Windows, ça a fait 16299 → 17134 → 17763 → 18362 → 18363 → 19041 → 19042 → 19043 → 19044 → 22000).
oui c’est gênant parce qu’on perd la notion de savoir si une sortie est « majeure » ou non.
je t’avoue que je préfère télécharger les versions qui apportent un vrai plus.
avec le système « codifié/standardisé » de numérotation de version on pouvait savoir si oui ou non ca valait le coup d’installer une nouvelle version lorsqu’on ne veut pas faire de nouvelles installations à chaque fois qu’on a changé la couleur du 3e menu (je n’utilise pas l’update automatique).
Voilà EXACTEMENT le problème que je pointais plus haut et qui à mon sens justifie totalement cet incrément systématique du numéro majeur sur les navigateurs : en distinguant des versions « majeures » et des versions « mineurs », les gens se mettent à zapper les mineures…
Or pour un navigateur, qui est un élément critique d’un point de vue sécurité, il FAUT considérer que TOUTES les versions sont majeures justement, parce qu’elles corrigent quasiment toujours des problèmes de sécurité.
S’il y a bien un logiciel qu’il faut absolument toujours maintenir à jour, c’est le navigateur.
Absolument pas. Parce qu’il n’y a pas un unique système « codifié/standardisé » de numérotation des versions… Et les systèmes qui sont vraiment codifiés/standardisés, comme semver ou libtool, ils ont en général une sémantique qui ne se base pas sur l’importance des changements du point de vue utilisateur, mais sur l’impact des changements du point de vue compatibilité (parce qu’en pratique, c’est bien plus souvent important de pouvoir déterminer de façon automatisée un changement de compatibilité que si une version a beaucoup de changements ou peu). Je n’ai pas connaissance d’un système de versionnage codifié qui se base sur l’ampleur des changements (d’autant plus que, comme je l’ai dit plus haut, l’ampleur des changements, c’est une notion totalement subjective, donc difficile à codifier… un changement mineur pour une personne peut être majeur pour une autre).
En semver, tu peux avoir un logiciel qui passe d’un simple viewer HTML à un navigateur complet, tout en n’incrémentant que le numéro de version mineur, alors que le simple abandon du support d’une balise HTML obsolète impliquera un changement du numéro de version majeur…
d’accord avec tout ça, dans ce cas qu’ils ne parlent plus de versions 99.0.1 suivie de 100.0.0
pourquoi ne pas continuer à incrémenter régulièrement les chiffres à chaque nouvelle sortie.
c’est à dire 99.0.1 puis 99.0.2 puis 99.0.3
qu’est ce qui justifie que l’on passe d’un coup à 100.0.0?