Commentaires : À son tour, Firefox passe en v100, et voici les nouveautés

Débat sur l'actu
23

Le fait qu’il s’agit d’une mise à jour planifiée, apportant des évolutions dans les fonctionnalités. Alors que 99.0.2, ça serait pour une mise à jour n’apportant que des corrections.

C’est comme ça qu’est codifié leur système de versionnage.

Le premier numéro est incrémenté à chaque cycle de release de la version standard du navigateur. Chaque cycle de release de la version standard embarque des fonctionnalités, des correctifs de bugs et des correctifs de sécurité. Ce sont des versions planifiées, qui sortent à intervalles réguliers, un cycle de release dure actuellement 4 semaines (on connait déjà les dates de sortie pour les versions 101 à 107).

Le second numéro est incrémenté à chaque cycle de correction de la version ESR du navigateur. Un cycle de correction ESR n’embarque que des correctifs de bugs et de sécurité, pas de fonctionnalités. La encore, ce sont des versions planifiées, avec le même cycle de 4 semaines que pour la version non ESR : la ESR x.y.0 sort à la même date que la standard x+y.0.0, et contient les même correctifs, sans les changements de fonctionnalité.

Le troisième numéro est incrémenté pour les correctifs urgents. C’est donc seulement lorsqu’il y a un défaut qui doit impérativement être corrigé très vite, sans attendre la fin du cycle (donc faille de sécurité particulièrement grave ou bug fortement gênant…). Là il s’agit de versions non planifiées, on ne connait à l’avance ni leur date de sortie, ni même leur existence.

Ainsi, on sait aujourd’hui que la 101.0.0 sortira le 31 mai, qu’il sortira en même temps une ESR 91.10, mais on ne sait pas si entre temps il y aura ou non une 101.0.1 et/ou une ESR 91.10.1 (pas nécessairement les deux à la fois : si le correctif urgent concerne une nouveauté des versions 92 à 100, il n’y aura pas de ESR 91.10.1, si il concerne une fonctionnalité supprimé entre la 92 et la 100, il y aura une ESR 91.10.1 mais pas de 100.0.1) ni à quelle date si jamais elle sort.

24

Ca change la possibilité ou non de suivre l’ampleur des évolutions sans lire les logs de toutes les versions précédentes par ex.

N’importe quoi, quand tu gères un progiciel tu es payé pour que ça marche, qu’un éditeur de middleware te complique la tâche avec du versionning branché yolo ne te relève pas de tes obligations. :roll_eyes:

Sauf que si une version est numérotée 99.1 il y a très peu de chance qu’elle casse une quelconque compatibilité si la numérotation reflète l’ampleur du changement.

Cette numérotation oblige juste à tout tester en intégralité à chaque MAJ de navigateur et limite donc la fluidité des grands comptes à migrer sur les dernières versions sécurisées puisque quand tu as plusieurs centaines d’applicatifs d’âges différents le résultat obtenu est juste un gel du SI tellement une évolution de navigateur est coûteuse.

C’est tellement absurde et sans intérêt comme fonctionnement que Mozilla a été obligé de créer la version ESR à part qui du coup est en 91.9.0 actuellement au max. Ce qui pourrit le fonctionnement BYOD des applis pour un intérêt final… nul à part pour faire la course du numéro de version avec Chrome en mode kikalaplugrosse.

25

Le but c’est justement aussi d’éviter ça… Pour éviter que les gens se disent « cette mise à jour est mineure, j’attends la prochaine majeure », alors que chaque mise à jour apporte son lot de correctifs de sécurité et doit donc être appliquée.

Tu parlais de quelqu’un qui s’est engagé contractuellement à supporter une version précise de Firefox. À partir du moment où la version change, il n’est donc bel et bien plus engagé.

Faux. C’est si la numérotation reflète la rétrocompatibilité qu’il y a peu (aucune en fait) de chances qu’une version mineure casse la compatibilité… C’est le cas avec le système semver ou libtool (et en pratique, la numérotation de Firefox, c’est quasiment du semver, parce que de fait, sur un logiciel aussi gros, chaque version a de fortes chances de modifier un comportement et donc de provoquer une rupture de compatibilité).

Si la numérotation reflète l’ampleur du changement, tu n’as strictement aucune information sur la compatibilité, car ce n’est pas l’ampleur du changement qui fait qu’il y a rupture de compatibilité, mais bien la nature du changement… Il peut y avoir rupture de compatibilité avec un changement absolument mineur, alors qu’à l’inverse un changement majeur n’implique pas forcément une rupture.

Cf l’exemple que j’ai donné plus haut, du simple viewer HTML qui deviendrait un navigateur complet. Avec un versionnage basé sur l’ampleur des changements, il changerait son numéro majeur, alors qu’il n’y a pas de rupture de compatibilité. À l’inverse, l’abandon du support d’une balise HTML obsolète ne changerait que le numéro mineur, alors qu’il y a cette fois rupture de compatibilité…

Donc au final, que tu passes de 99 à 99.1 ou à 100, tu dois dans tous les cas te retaper tous les tests, puisque rien ne te garanti que la 99.1 ne casse pas la compatibilité (faut prendre les ESR pour ça, c’est leur rôle).

Non, c’est indépendant. L’idée de l’ESR, c’est justement d’avoir une branche qui reçoit toutes les mises à jours correctives et de sécurité mais sans les mises à jour fonctionnelles qui risquent de casser la compatibilité.

Si Firefox 92 avait été numéroté 91.1 au lieu de 92, ça n’éviterait pas aussi le besoin d’un Firefox 91.1 ESR, 100% compatible avec la 91.0 (ce que ne serait pas la 92/91.1 classique, qui est une mise à jour fonctionnelle), mais avec tous les correctifs de la 92/91.1. Par contre ça rendrait quelque peu compliqué la numérotation, puisque du coup la 91.1 classique et la 91.1 ESR auraient le même numéro, alors qu’elles n’ont pas le même contenu…

Quelque soit la façon de numéroter, la seule façon de rendre le même service que l’ESR sans faire une branche ESR séparée, ça serait de ne faire des mises à jour fonctionnelles qu’une fois par an (donc en fait de ne garder que la branche ESR, pas l’autre). Mais ça dans le domaine des navigateurs ça n’est plus viable, tu peux pas te permettre d’attendre un an pour supporter des choses que les navigateurs concurrents supportent déjà. Et en plus, ça permet de tester les nouveautés à plus grande échelle avant de les déployer en entreprise.

26

L’effet inverse est obtenu.

En concret ça contraint les gens à bloquer les MAJ de navigateurs surtout.

C’est faux, la plupart des progiciels sont sur des fonctions très standards au coeur des navigateurs, fonctions qui ne sont touchées que par des changements structurels car sinon totalement couvertes par des tests automatisés bloquant les release.

Il n’y a quasi pas d’abandons de balises HTML dans l’histoire des navigateurs (< blink >? :sweat_smile: ), la plupart des fonctions nouvelles justifiant ce rythme de sortie consistent dans le support de nouveaux formats médias, de mécanismes réseau de compression ou de CSS etc.

Tu as l’air 100% persuadé que les 9 versions de delta ont cassé une quelconque rétrocompatibilité. Il y a de grandes chances que non (pour du progiciel en tous cas) et c’est ce qui rend ce delta de 9 versions absurde.

Pour ça il y a les developper preview, pas les branches « main » grand public des middleware.

27

En es-tu certain ? Perso c’est vraiment pas l’impression que j’ai, bien au contraire, je vois actuellement des navigateurs presque toujours à jour chez tout le monde, ce qui était loin d’être le cas avant…

En quoi ça contraint plus qu’avant ? De toute façon avec une numérotation basée sur l’ampleur des nouveautés (ce qui est de toute façon totalement arbitraire comme notion), il n’y a pas plus de garantie qu’un 99.1 est 100% compatible avec ce qui marche sur un 99.0 que de garantie qu’un 100.0 est 100% compatible avec ce qui marche sur un 99.0… Donc celui qui a besoin de rester 100% compatible avec la 99.0, il bloquera dans tous les cas les mises à jour…

Encore une fois, une numérotation basée sur l’ampleur des modifications ne dit strictement RIEN sur la compatibilité.

Oui et non. Le moteur de rendu HTML évolue à chaque version vers plus de conformité avec les standards. Mais ça peut casser du coup les logiciels qui tenaient compte d’un défaut de conformité du navigateur et implémentaient un contournement… La release du navigateur ne sera pas bloquée par les tests automatiques (puisqu’elle obtient de meilleurs résultats), mais elle cassera quand même la compatibilité avec certaines applications…

Au niveau des balises HTML, c’est effectivement rare. Il y a par contre des abandons au niveau des protocoles (SPDY, TLS 1.1 par exemple), de certaines fonctionnalités avancées (par exemple le cache manifest pour les web apps), de l’API des extensions, ou encore des protections de la vie privée (quand le navigateur se met à bloquer automatiquement certaines choses, ça fout bien en l’air la compatibilité parfois…). Et surtout, il y a les corrections de bug de rendu, qui de fait peuvent casser la compatibilité avec toutes les pages ayant contourné ce bug…

Et il peut aussi y avoir des ruptures de compatibilité au niveau de l’installation, comme c’est d’ailleurs le cas avec Firefox 100, qui ne peut plus s’installer sur un Windows 7 sans la mise à jour KB4474419 (passage d’une signature SHA-1 à SHA-256 pour renforcer la sécurité).

On parle de Firefox là. Ce n’est pas un middleware. Et les versions développeurs servent pour bénéficier de manière anticipée de nouvelles fonctionnalités qui vont arriver dans le navigateur, pour commencer à développer des pages les utilisant, ça n’est pas comparable à un « test » à grande échelle de nouveautés avant leur déploiement en entreprise…

28

Vue tes problématiques utilise la version ESR elle est faite pour ça.