Les développeurs de Firefox ont annoncé une réduction du cycle de publication des nouvelles versions du navigateur à quatre semaines (contre six à huit semaines auparavant). Firefox 70 sera donc disponible le 22 octobre, comme prévu , suivi six semaines plus tard, le 3 décembre, par Firefox 71. Les mises à jour suivantes seront publiées toutes les quatre semaines (7 janvier, 11 février, 10 mars, etc.).
Par conséquent, la version à support à long terme (LTS) sera publiée annuellement comme auparavant et maintenue pendant trois mois après la sortie de la version LTS suivante. Les correctifs pour la branche LTS seront synchronisés avec les versions régulières et publiés toutes les quatre semaines.
La prochaine version ESR sera Firefox 78, prévue pour juin 2020. SpiderMonkey et Tor Browser passeront également à un cycle de publication de 4 semaines.
Le raccourcissement du cycle de développement vise à proposer plus rapidement de nouvelles fonctionnalités aux utilisateurs. Des mises à jour plus fréquentes devraient accroître la flexibilité de la planification du développement produit et faciliter la mise en œuvre des changements prioritaires répondant aux exigences du marché et de l'entreprise.
D'après les développeurs, le cycle de développement de quatre semaines permet un équilibre optimal entre la rapidité de mise en œuvre des nouvelles API web et la garantie de la qualité et de la stabilité.
À partir du premier trimestre 2020, nous prévoyons de livrer une version majeure de Firefox toutes les 4 semaines. La cadence de publication de Firefox ESR (Extended Enterprise Support Release) restera la même.
Dans les années à venir, nous prévoyons une version ESR majeure tous les 12 mois avec un chevauchement de support de 3 mois entre le nouvel ESR et la fin de la vie utile de l'ancien ESR. Les deux prochaines versions majeures d'ESR seront ~ juin 2020 et ~ juin 2021.
Des cycles de lancement plus courts offrent une plus grande flexibilité pour prendre en charge la planification des produits et les changements de priorité en raison des exigences commerciales ou du marché.
Avec des cycles de quatre semaines, nous pouvons être plus agiles et livrer les fonctionnalités plus rapidement, tout en appliquant la même rigueur et la même diligence raisonnable requises pour une version stable et de haute qualité.
De plus, nous mettons plus rapidement les nouvelles fonctionnalités et la mise en œuvre de nouvelles API Web entre les mains des développeurs. (C'est ce que nous avons fait récemment avec les implémentations et les mises à jour des spécifications CSS, par exemple.)
La réduction du temps nécessaire à la préparation d'une version entraînera une réduction du temps de test pour les versions bêta , les versions de développement nocturnes et les éditions pour développeurs, réduction qui sera compensée par des mises à jour plus fréquentes pour les versions de test.
Au lieu de préparer deux nouvelles versions bêta par semaine , il est prévu d'adapter le schéma de publication bêta fréquent pour la branche bêta , qui était auparavant utilisé pour les versions nocturnes.
Pour maintenir la qualité et minimiser les risques dans un cycle raccourci, nous devons:
- Assurez-vous que la productivité de l'ingénierie de Firefox n'est pas affectée.
- Accélérez la boucle de retour de régression du déploiement à la détection et à la résolution.
- Être capable de contrôler le déploiement des fonctions en fonction de la disponibilité de la version.
- Assurez-vous de tester correctement les fonctionnalités plus importantes couvrant plusieurs cycles de publication.
- Avoir des processus d'atténuation et de décision clairs et cohérents.
Afin de réduire le risque de problèmes imprévus lors de l'ajout d'innovations importantes , les changements qui y sont associés seront déployés auprès des utilisateurs des versions non pas tous en même temps, mais progressivement ; dans un premier temps, la fonctionnalité sera activée pour un petit pourcentage d'utilisateurs, puis elle sera entièrement couverte ou désactivée dynamiquement lorsque des défauts seront découverts.
De plus, pour tester les innovations et prendre des décisions quant à leur inclusion dans l'équipe principale du programme Test Pilot, les utilisateurs seront invités à participer à des expériences qui ne sont pas liées au cycle de préparation du lancement.
Source : https://hacks.mozilla.org/