Chrome acelera a dos semanas: Extended Stable conserva ocho
Google activó el 8 de septiembre de 2026 el nuevo calendario de Chrome: desde Chrome 153, las versiones Stable para escritorio, Android e iOS pasan de un ciclo de cuatro semanas a otro de dos. El anuncio de Chrome situó además a Chrome 154 Beta en pruebas y programó su llegada a Stable para el 22 de septiembre.
El cambio ya está en producción, no es un plan pendiente. La cobertura de TechCrunch corroboró el 8 de septiembre el lanzamiento de Chrome 153 en las tres plataformas y el paso al ciclo quincenal. Para desarrolladores y administradores, esto reduce a la mitad el intervalo entre hitos de Stable, mientras Extended Stable conserva versiones principales cada ocho semanas.
Dos calendarios desde Chrome 153
La nueva frecuencia se refiere a los hitos de Stable, que pueden incorporar funciones, mejoras de rendimiento y correcciones. Chrome prevé entregas de menor alcance y sostiene que eso permitirá aislar regresiones con más rapidez; la contrapartida para quienes mantienen sitios, extensiones o flotas es una ventana más corta entre versiones.
Extended Stable no queda ocho semanas sin mantenimiento. La documentación de Chrome Enterprise establece un hito nuevo cada ocho semanas y refrescos semanales con correcciones de seguridad retroportadas desde Stable cuando sea técnicamente posible. Durante las primeras dos semanas, ambos canales comparten el mismo hito; después, la rama extendida se mantiene seis semanas más.
La misma documentación limita Extended Stable a navegadores administrados en Windows y macOS: no está disponible para Android ni iOS y se gestiona mediante la política TargetChannel. También advierte que, aunque se intenta retroportar las correcciones de gravedad crítica, alta y media, ciertos cambios complejos o funciones amplias relacionadas con la seguridad pueden aparecer únicamente en Stable.
Por tanto, “dos semanas” y “ocho semanas” describen la llegada de nuevas versiones principales, mientras que los refrescos de seguridad siguen su propio calendario. Extended Stable reduce la frecuencia de los saltos de hito, pero no ofrece una equivalencia completa con la rama Stable durante las seis semanas adicionales.
Beta pasa a marcar el ritmo de las pruebas
Para los desarrolladores web, esperar a que una versión llegue a Stable deja menos margen para detectar una incompatibilidad, corregirla y desplegar la solución antes del siguiente hito. La respuesta operativa es tratar cada Beta quincenal como una ventana de validación, no como una comprobación ocasional.
Una lista compacta y verificable para cada ciclo puede incluir:
- registrar el número exacto de Beta y ejecutar la misma batería contra la Stable que continúa en producción;
- probar autenticación, pagos, carga de archivos, impresión y los demás recorridos críticos del producto;
- comprobar las API web utilizadas, los permisos, las extensiones y las integraciones dependientes del navegador;
- comparar errores de consola, fallos de automatización y métricas de rendimiento con una línea base conocida;
- asignar a cada regresión un responsable, una fecha límite y un criterio explícito de bloqueo.
El objetivo no es duplicar manualmente todas las pruebas. Una canalización automatizada puede ejecutar el mismo conjunto contra Stable y Beta, mientras la revisión humana se concentra en recorridos de alto impacto. El informe debe identificar siempre el canal y el hito examinados: que una aplicación funcione en Extended Stable no demuestra que sea compatible con la próxima Stable.
Stable y Extended Stable exigen despliegues distintos
Una flota empresarial tiene ahora dos compromisos operativos. Stable reduce la espera para recibir funciones y cambios que no pueden retroportarse, pero obliga a validar y distribuir hitos con mayor frecuencia. Extended Stable deja más tiempo entre cambios funcionales, aunque mantiene durante seis semanas adicionales una rama anterior y puede no recibir determinadas mejoras complejas.
La separación más útil no es solo por dispositivo, sino por función. Un grupo piloto en Stable o Beta puede revelar incompatibilidades antes de que el hito llegue a la mayoría de los usuarios, mientras los equipos que dependen de aplicaciones especialmente sensibles permanecen en Extended Stable. La recomendación editorial es registrar para cada grupo el sistema operativo, el canal, el hito instalado y la fecha del último refresco.
Ese inventario evita interpretar el ciclo de ocho semanas como permiso para retrasar correcciones semanales. También permite comprobar si las ventanas de reinicio, los controles de versión y las herramientas de distribución pueden absorber dos hitos de Stable al mes sin ocultar equipos rezagados.
El coste de conservar ocho semanas
Extended Stable conserva tiempo para evaluar cambios funcionales; no conserva todas las novedades ni garantiza la retroportación de cualquier modificación de seguridad. Su ventaja es reducir los saltos de versión principal. Su coste es sostener una rama anterior durante más tiempo, vigilar las excepciones técnicas y mantener cobertura de pruebas para dos hitos distintos.
Para un proveedor web, esa bifurcación amplía la matriz de compatibilidad: debe comprobar el Chrome Stable reciente y el hito que continúa activo entre clientes administrados. Para un administrador, desplazar más equipos al canal extendido reduce la frecuencia de migración, pero también aumenta la importancia del grupo piloto y del seguimiento de los refrescos semanales.
El estado confirmado de la transición es concreto: Chrome 153 inició el ciclo quincenal el 8 de septiembre de 2026 y Chrome 154 era el siguiente hito Stable previsto para el 22 de septiembre. Extended Stable mantiene sus hitos de ocho semanas y sus refrescos semanales; los próximos ciclos mostrarán qué cambios no pueden retroportarse y cuánto trabajo adicional genera la nueva frecuencia en pruebas y soporte.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.