Tweet
Il y a quelques semaines, nous vous avions indiqué que Mozilla se préparait non seulement à publier la version finale de Firefox 4, mais également à changer de méthode de développement. L’objectif était particulièrement imposant : lancer trois autres versions majeures du navigateur durant l’année 2011. Un cycle si différent de ce que tout l’éditeur a fait jusqu’à présent qu’on s’attendait à ce que les développeurs revoient de fond en comble le processus de création. On en sait désormais davantage, et Mozilla n’en démord pas : il faut accélérer.
Un cycle actuellement très long
Firefox 4 doit arriver le 22 mars, et il s’agira sans le moindre doute de la plus importante mouture du navigateur jamais sortie. D’abord parce que les nouveautés et améliorations sont très nombreuses mais aussi, et surtout, parce qu’il a fallu pas moins de douze bêtas et deux Release Candidates avant d’en arriver là. Un processus très long dont Mozilla ne peut plus se payer le luxe, face à une concurrence déchainée et plus particulièrement un Chrome qui a avancé de dix versions en seulement deux ans.
En comptant la sortie de Firefox 4 et les objectifs de Mozilla, on arriverait donc à un Firefox 7 d’ici la fin de cette année. L’approche actuelle pour le développement du produit est très classique, voire conservatrice. On fixe une série d’objectifs à atteindre, et on fait ce qu’il faut pour y parvenir. Dans le cas de Firefox 4, qui contient de nombreux objectifs, le temps nécessaire s’allonge. Pour peu que des changements architecturaux interviennent, la durée s’allonge encore, et la phase de test (les bêtas) augmente en conséquence.
Un moteur qui doit tourner à plein régime
Mozilla a publié un document expliquant comment les choses vont désormais fonctionner. Le dépôt mozilla-central va servir de cycle de développement permanent dans lequel les nouveautés arrivent sans cesse. De temps en temps, une fenêtre s’ouvre et il y a arrêt sur image : cet instantané est envoyé en branche expérimentale. En fonction des tests, on remonte d’un cran et on passe en bêta, puis à un lancement public. On pourait comparer la méthode à un mixer dont un clapet permettrait de goûter la préparation au fur et à mesure que l’on ajoute des ingrédients.
De fait, la conséquence la plus directe est que les nouveautés n’apparaissent toujours que dans mozilla-central : jamais dans la branche expérimentale ou bêta. Quand un instantané remonte dans la branche expérimentale, son destin n’est pas forcément de passer en bêta par la suite. Si une fonctionnalité ou une technologie ne donne pas satisfaction, elle repart dans mozilla-central jusqu’à une prochaine ouverture.
Bien sûr, chacun de ces quatre jalons dispose de son propre public, que Mozilla évalue comme suit :
Plus on s’éloigne de mozilla-central, plus les utilisateurs sont nombreux. L’éditeur compte ainsi 100 000 utilisateurs environ pour les versions mozilla-central, qui seront dépositaires de toutes les nouveautés, mais qui seront instables. Les trois jalons suivants sont à considérer comme des étapes de stabilisation.
Le graphique ci-dessus représente le temps estimé passé sur chaque étape. Comme on peut le voir, Mozilla table sur environ six semaines par étape, mais elles peuvent se chevaucher. On obtient un rythme global basé sur seize semaines. Mais on remarque surtout qu’avec ce système, toutes les étapes de la chaine fonctionnent toujours à plein régime. Ainsi, dès qu’une version expérimentale passe en phase bêta, une autre prend sa place.
Des problèmes en perspective
La publication régulière de nouvelles versions pose différents challenges. L’un de ceux soulevés concerne le processus de mise à jour. Le système peut se montrer intrusif, et Mozilla réfléchit donc à rendre l’ensemble complètement silencieux. C’est ce qui se passe actuellement avec les bêtas de Firefox 4, mais cette procédure n’est censée être utilisée que pour les corrections, et non pour les versions majeures. Finalement, Firefox 5, 6, 7 et les suivants pourraient utiliser la méthode de Chrome, qui ne dit pratiquement jamais rien à l’utilisateur.
Mais la plus grande épreuve qui attend Firefox ne réside pas forcément sur les efforts des développeurs de Mozilla, mais sur les développeurs tiers. En effet, Firefox est devenu particulièrement célèbre pour son écosystème très riche d’extensions. Bien que le kit Jetpack permette la création d’une nouvelle génération plus légère, ne nécessitant pas de redémarrage et non affiliée à une version précise du navigateur, la grande majorité reste classique. Chaque version majeure de Firefox casse la compatibilité une bonne partie de l’écosystème, et les développeurs doivent suivre.
Il reste donc des problèmes à résoudre, et le document publié par Mozilla n’est qu’un brouillon. Les choses peuvent encore évoluer, mais l’éditeur semble avoir réfléchi à la question depuis un moment, et il y a des chances que la méthode retenue soit très proche de ce qu’on peut y lire.
Un cycle actuellement très long
Firefox 4 doit arriver le 22 mars, et il s’agira sans le moindre doute de la plus importante mouture du navigateur jamais sortie. D’abord parce que les nouveautés et améliorations sont très nombreuses mais aussi, et surtout, parce qu’il a fallu pas moins de douze bêtas et deux Release Candidates avant d’en arriver là. Un processus très long dont Mozilla ne peut plus se payer le luxe, face à une concurrence déchainée et plus particulièrement un Chrome qui a avancé de dix versions en seulement deux ans.
En comptant la sortie de Firefox 4 et les objectifs de Mozilla, on arriverait donc à un Firefox 7 d’ici la fin de cette année. L’approche actuelle pour le développement du produit est très classique, voire conservatrice. On fixe une série d’objectifs à atteindre, et on fait ce qu’il faut pour y parvenir. Dans le cas de Firefox 4, qui contient de nombreux objectifs, le temps nécessaire s’allonge. Pour peu que des changements architecturaux interviennent, la durée s’allonge encore, et la phase de test (les bêtas) augmente en conséquence.
Un moteur qui doit tourner à plein régime
Mozilla a publié un document expliquant comment les choses vont désormais fonctionner. Le dépôt mozilla-central va servir de cycle de développement permanent dans lequel les nouveautés arrivent sans cesse. De temps en temps, une fenêtre s’ouvre et il y a arrêt sur image : cet instantané est envoyé en branche expérimentale. En fonction des tests, on remonte d’un cran et on passe en bêta, puis à un lancement public. On pourait comparer la méthode à un mixer dont un clapet permettrait de goûter la préparation au fur et à mesure que l’on ajoute des ingrédients.
De fait, la conséquence la plus directe est que les nouveautés n’apparaissent toujours que dans mozilla-central : jamais dans la branche expérimentale ou bêta. Quand un instantané remonte dans la branche expérimentale, son destin n’est pas forcément de passer en bêta par la suite. Si une fonctionnalité ou une technologie ne donne pas satisfaction, elle repart dans mozilla-central jusqu’à une prochaine ouverture.
Bien sûr, chacun de ces quatre jalons dispose de son propre public, que Mozilla évalue comme suit :
Plus on s’éloigne de mozilla-central, plus les utilisateurs sont nombreux. L’éditeur compte ainsi 100 000 utilisateurs environ pour les versions mozilla-central, qui seront dépositaires de toutes les nouveautés, mais qui seront instables. Les trois jalons suivants sont à considérer comme des étapes de stabilisation.
Le graphique ci-dessus représente le temps estimé passé sur chaque étape. Comme on peut le voir, Mozilla table sur environ six semaines par étape, mais elles peuvent se chevaucher. On obtient un rythme global basé sur seize semaines. Mais on remarque surtout qu’avec ce système, toutes les étapes de la chaine fonctionnent toujours à plein régime. Ainsi, dès qu’une version expérimentale passe en phase bêta, une autre prend sa place.
Des problèmes en perspective
La publication régulière de nouvelles versions pose différents challenges. L’un de ceux soulevés concerne le processus de mise à jour. Le système peut se montrer intrusif, et Mozilla réfléchit donc à rendre l’ensemble complètement silencieux. C’est ce qui se passe actuellement avec les bêtas de Firefox 4, mais cette procédure n’est censée être utilisée que pour les corrections, et non pour les versions majeures. Finalement, Firefox 5, 6, 7 et les suivants pourraient utiliser la méthode de Chrome, qui ne dit pratiquement jamais rien à l’utilisateur.
Mais la plus grande épreuve qui attend Firefox ne réside pas forcément sur les efforts des développeurs de Mozilla, mais sur les développeurs tiers. En effet, Firefox est devenu particulièrement célèbre pour son écosystème très riche d’extensions. Bien que le kit Jetpack permette la création d’une nouvelle génération plus légère, ne nécessitant pas de redémarrage et non affiliée à une version précise du navigateur, la grande majorité reste classique. Chaque version majeure de Firefox casse la compatibilité une bonne partie de l’écosystème, et les développeurs doivent suivre.
Il reste donc des problèmes à résoudre, et le document publié par Mozilla n’est qu’un brouillon. Les choses peuvent encore évoluer, mais l’éditeur semble avoir réfléchi à la question depuis un moment, et il y a des chances que la méthode retenue soit très proche de ce qu’on peut y lire.
Commentaire