Mozilla a annoncé hier soir un changement dans le rythme de publication des versions de Firefox. D’un cycle strict basé sur un roulement de six semaines, les futures évolutions pourront nécessiter jusqu’à huit semaines. Explications.
Beaucoup ne s’en rappellent peut-être pas, mais c’est Chrome qui a instauré ce qui a fini par devenir une règle d’or pour Mozilla, puis Opera : une nouvelle version toutes les six semaines. Il s’agit d’un roulement permanent sur trois canaux : un premier dans lequel les nouveautés brutes sont intégrées au code (les Nightlies, ou Canary pour Chrome), un ou deux canaux de test en fonction de la qualité du code (Aurora et bêta), puis la version de production, celle qui est envoyée finalement à tous les utilisateurs.
Les Nightlies, et dans une moindre mesure les versions Aurora et bêta, peuvent s’apparenter à une cuve dans laquelle Mozilla prépare ses nouveautés. Toutes les six semaines, une valve est ouverte pour filtrer ce qui est prêt à être testé par la communauté. Si le résultat est jugé probant, la nouveauté est confirmée dans la version finale.
Mais Mozilla possède également certains projets au long cours qu’il prévoit longtemps à l’avance, tout en prévoyant d’éventuels retards. Ce fut le cas par exemple pour la transition vers GTK3 pour la mouture Linux, qui devait arriver dans Firefox 43 mais qui ne sera finalement là que dans la version 45 (actuellement en bêta).
De six à huit semaines, en fonction du contexte
Ce rythme de six semaines, en place depuis quatre ans chez Mozilla, a fait l’objet d’une analyse constante. L’éditeur explique dans un billet qu’après de nombreux retours, il a décidé de basculer sur un cycle plus souple, allant de six à huit semaines, pour tenir compte de certains paramètres (comme les périodes de vacances des employés, ou le temps nécessaire pour finaliser une fonctionnalité particulière). De fait, le planning est devenu très précis.
- 3 mars 2016 : Firefox 45 et ESR 45 (six semaines après la 44)
- 19 avril 2016 : Firefox 46 (six semaines)
- 7 juin : Firefox 47 (sept semaines)
- 2 août : Firefox 48 (huit semaines)
- 13 septembre : Firefox 49 (six semaines)
- 8 novembre : Firefox 50 (huit semaines)
- 13 décembre : Firefox 50.0.1 (cinq semaines, version d’entretien)
- 21 janvier : Firefox 51 (six semaines)
Le planning s’étale donc sur une année, et il y a probablement de nombreuses variables non maitrisées en jeu. Ces dates sont d'ailleurs toutes susceptibles d’évoluer, d’autant qu’il suffit d’un retard sur l’une des première pour créer un effet domino sur les autres.
La branche ESR suivra le même rythme
On remarque quoi qu’il en soit que deux versions particulières vont réclamer huit semaines, mais les raisons peuvent en être très différentes. Firefox 48 arrivera ainsi le 8 août, en pleine période estivale. Il y a de fortes chances que Mozilla tienne compte des nombreux congés posés par les employés durant cette période.
Par contre, Firefox 50 a plus probablement une valeur symbolique étant donné son numéro de version. Mozilla prévoit peut-être des fonctionnalités bien précises ou peut simplement compter sur un contrôle qualité plus intensif.
Enfin, précisons que la nouvelle version ESR 45, avec son support allongé, bénéficiera d’une mise à jour à chaque sortie d’un nouveau Firefox. Ainsi, quand la version 46 arrivera le 19 avril prochain, les utilisateurs de la branche recevront de leur côté un Firefox ESR 45.1. Le fonctionnement sera le même jusqu’à l’année prochaine, avec une ESR 4.6 pour l’arrivée de Firefox 51.
Ceux qui souhaitent obtenir plus de précisions sur ce cycle pourront consulter la page dédiée dans le wiki de l’éditeur.
Commentaires (33)
#1
Dire qu’au boulot nous ne sommes passés récemment qu’a la version 24 ESR de Firefox…
#2
Ah, la prochaine aura une ESR. Ça va permettre à Tor Browser de se mettre à jour
" />
" />
Sinon, je comprends pas trop le coup de la 50.0.1. 10 mois à l’avance, ils savent qu’il y aura des corrections critiques (si j’en crois le billet de blog) à faire
#3
Il était temps, ça n’avait plus de sens depuis quelques versions…
#4
A voir le planning ça ne change pas grand chose au final ! Je m’attendais à plusieurs mois entres les sorties
Sait on si on aura une version 45 pour Thunderbird ?
#5
#6
#7
Ça sens la mise en place des WebExtensions cette version 50.
" />
#8
N’empêche, merci Chrome d’avoir lancé le mouvement de “une correction de bug = une nouvelle version”. D’ici quelques années, on va se retrouver à Firefox 500 versus Chrome 700…
#9
En même temps, l’utilisateur final s’en tape du n° de version, et perso, pour trier les bugs ou indiquer une version à partir de laquelle commence une régresssion, je préfère le versioning entier que le décimal à base de version 3.5.12.
#10
En tant que dèv web, je préfère cette notation. C’est plus clair pour savoir depuis quand est supporté quoi. J’ai l’impression qu’il y en a qui n’ont pas continence du nombre de modifs par perversion :
Par exemple, juste pour les dévs : Firefox 44. Perso, ça me permet de suivre. Pour les utilisateurs, c’est complètement anecdotique. Ça serait 12.2.4 ou 42.1 que ça ne changerais rien. Quand je vois que je me sers d’Inskcape depuis des années et que la version 1 ne semble jamais venir, ça me fait le même effet : ça fonction et je m’en fous du choix du versionning.
#11
Ce qui a le don de m’énerver , c’est de voir que des banques, des ministères, des grosses boites fixent dans le marbre Firefox à la version 24, ou 36 alors que depuis que je fais du dev, je n’ai jamais eu une application qui a cessé de fonctionner en passant de la 38 à la 39 ou de la 41 à la 44 de firefox. (je ne parle pas des jeux sous flash ou des extensions et autres plugin , mais des vraies applications métiers. Firefox, ce n’est ni IE qui est incompatible avec lui même quand on passe de la 6 à la 8 ou de la 9 à la 10, et je ne parle même pas de Chrome qui n’en fait qu’a sa tête et qui est en train de devenir le navigateur le moins compatible avec les standards du web. Dans notre équipe de dev travaille tous avec firefox, l’un des nôtres teste régulièrement avec IE 9-10-et 11 (demande client) mais chaque fois qu’il y a un truc qui marche pas, c’est avec Chrome.
#12
#13
#14
Mais mais pourquoi ie 8 ? Ils veulent que tu parte de ta société ?
#15
Eh oué ! C’est que ces gens ne veulent pas être emmer
Genre il faut les droits d’admin pour faire une upgrade de version, quand le service de màj Mozilla foire (du vécu
Perso, au taf, j’ai pu expérimenter THE bug !
Suite à un upgrade automatique de version, genre 31 vers 32 (je me rappelle plus exactement), tous les PC avec de vieux drivers Intel Graphics ont fait un gros Black Screen au lancement de Firefox.
Je peux te dire que ça fait drôle quand tout un pool d’utilisateurs te tombe dessus, et que tu dois fissa comprendre le problème et le corriger…
Bref, rien de mieux qu’on bon vieux lockPref(“app.update.enabled”, false); dans un fichier de config et hop ! plus d’updates, plus d’embrouilles !
#16
Quand la communauté mozilla ce sera tiré une balle dans le pied, ce sera l’unique fois ou ils auront regardé plus loin que leurs nombril
#17
De toute façon, PaleMoon domine largement firefox.
#18
Ah je vois que Chrome pose problème à d’autres ! Je développe rien, mais ma société offre un portail professionnel, et on a pas mal de soucis (mineurs) avec Chrome.
Chrome is the new IE6 ? J’espère pas, car on va retomber dans les mêmes travers, la course folle aux nouvelles versions en plus !
#19
Pour les PC plus anciens dans Firefox je désactive l’accélération graphique et idem dans Flash, ça m’a sauvé plus d’une fois…
#20
#21
Si dans les faits y’a pas de régression, tout bon SI se doit de faire une TNR avant de déployer une nouvelle version d’application. Et une TNR, ça coûte du temps et je doute que tous les SI aient envie d’en faire une toutes les 2 semaines.
Si tu laisses les mises à jour auto et que demain la compatibilité saute du jour au lendemain, les utilisateurs risquent de moins apprécier. Et intervenir en mode pompier pour faire un rollback, c’est un peu la dèche quoi.
#22
Ca me semble être un choix pragmatique de s’adapter à ses developpeurs et à la complexité du projet.
La réalité prime toujours sur un planning figé, dans tous les projets de toutes les industries. Les gens ne peuvent s’adapter à un planning précontraint que dans une certaine limite, et toujours au détriment de la qualité finale du produit et des petits détails qui font toute la différence.
Et perso, je n’avais pas compris à l’époque cette idée loufoque de suivre Google à la lettre dans le cycle de 6 semaines. A entreprise et produit différents, méthodes différentes de gestion de projets.
Bref très bien.
#23
Waaw je me souviens encore quand Firefox a decider d’accélérer et de passer de la version 3.x.x à 4 .
Et là on est a 43 !!
#24
#25
#26
#27
#28
Mozilla a tout compris !
" /> 
" />
#29
Et c’est bien dommage
" />