Los desarrolladores de Firefox han anunciado una reducción en el ciclo de preparación de nuevas versiones del navegador a cuatro semanas (las versiones anteriores se preparaban para 6-8 semanas). Firefox 70 se lanzará de acuerdo con el calendario anterior el 22 de octubre, luego, seis semanas más tarde, el 3 de diciembre, se preparará la versión Firefox 71, después de lo cual se formarán lanzamientos posteriores cada cuatro semanas (7 de enero, 11 de febrero, 10 de marzo, etc.).

Con lo cual la versión de largo plazo de soporte (ESR) se lanzará una vez al año como antes y se mantendrá durante otros tres meses después de la formación de la próxima version de ESR. Las actualizaciones correctivas para la rama ESR se sincronizarán con las versiones regulares y también se lanzarán cada 4 semanas.

La próxima versión de ESR será Firefox 78, programada para junio de 2020. SpiderMonkey y Tor Browser también se cambiarán a un ciclo de generación de lanzamiento de 4 semanas.

La razón para acortar el ciclo de desarrollo es el deseo de traer más rápidamente nuevas funciones a los usuarios. Se espera que los lanzamientos más frecuentes aumenten la flexibilidad de la planificación del desarrollo de productos y la implementación de cambios prioritarios que cumplan con los requisitos de las empresas y el mercado.

Según los desarrolladores, el ciclo de desarrollo de cuatro semanas permite lograr un equilibrio óptimo entre la velocidad de proporcionar nuevas API web y garantizar la calidad y la estabilidad.

A partir del primer trimestre de 2020, planeamos enviar una versión principal de Firefox cada 4 semanas. La cadencia de lanzamiento de Firefox ESR ( versión de soporte extendido para la empresa) seguirá siendo la misma.

En los años venideros, anticipamos un lanzamiento importante de ESR cada 12 meses con una superposición de soporte de 3 meses entre el nuevo ESR y el final de la vida útil del ESR anterior. Las próximas dos versiones principales de ESR serán ~ junio de 2020 y ~ junio de 2021.

Los ciclos de lanzamiento más cortos brindan una mayor flexibilidad para respaldar la planificación del producto y los cambios de prioridad debido a los requisitos comerciales o del mercado.

Con ciclos de cuatro semanas, podemos ser más ágiles y enviar funciones más rápido, al tiempo que aplicamos el mismo rigor y la debida diligencia necesarios para un lanzamiento estable y de alta calidad.

Además, ponemos nuevas funciones e implementación de nuevas API web en manos de los desarrolladores más rápidamente. (Esto es lo que hemos estado haciendo recientemente con implementaciones y actualizaciones de especificaciones CSS, por ejemplo).

La reducción del tiempo necesario para preparar el lanzamiento conducirá a una reducción en el tiempo de prueba para los lanzamientos beta, las versiones nightly y las ediciones para desarrolladores, que se planea compensar con actualizaciones más frecuentes para las versiones de prueba.

En lugar de preparar dos nuevas versiones beta por semana, se planea adaptar el esquema de lanzamiento frecuente beta para la rama beta, que se usaba anteriormente para las versiones nocturnas.

Para mantener la calidad y minimizar el riesgo en un ciclo acortado, debemos:

• Asegurarse de que la productividad de ingeniería de Firefox no se vea afectada negativamente.
• Acelerar el ciclo de retroalimentación de regresión desde el despliegue hasta la detección y la resolución.
• Poder controlar el despliegue de funciones en función de la disponibilidad de la versión.
• Asegure pruebas adecuadas de características más grandes que abarcan múltiples ciclos de lanzamiento.
• Tener procesos claros y consistentes de mitigación y decisión.

Para reducir el riesgo de problemas imprevistos al agregar algunas innovaciones significativas, los cambios asociados con ellos se llevarán a los usuarios de las versiones no una vez, sino gradualmente; al principio, la oportunidad se activará para un pequeño porcentaje de usuarios y luego se cubrirá por completo o se desconectará dinámicamente cuando se descubran defectos.

Además, para probar las innovaciones y tomar decisiones sobre su inclusión en el equipo principal del programa Test Pilot, se invitará a los usuarios a participar en experimentos que no están vinculados al ciclo de preparación del lanzamiento.

Fuente: https://hacks.mozilla.org/