Google ha anunciado un cambio en la cadencia de actualizaciones de Chrome: a partir del lanzamiento de Chrome 153, previsto para el 8 de septiembre, el navegador pasará de una versión estable cada cuatro semanas a publicar dos versiones estables al mes. En la práctica esto significa que los cambios, correcciones y pequeñas mejoras llegarán con mayor frecuencia, aunque con un alcance menor en cada entrega para intentar mantener la estabilidad.
Según la información publicada por el equipo de Chromium, esta modificación afecta tanto a los canales Beta como a los estables en escritorios y dispositivos móviles (Android e iOS). Los canales orientados a desarrollo temprano —Dev y Canary— seguirán conservando su ritmo actual de publicaciones, y la rama Extended Stable, pensada para clientes empresariales que necesitan ventanas de actualización más largas, permanecerá en su ciclo de ocho semanas. Puedes revisar la documentación oficial y el historial de publicaciones en el blog de Chromium y en el sitio de Chrome Releases: blog.chromium.org y chromereleases.googleblog.com.

¿Por qué dar este paso ahora? Desde Google señalan que paquetes de cambios más pequeños facilitan la localización de errores y reducen la disrupción para usuarios y administradores. Actualizar con mayor frecuencia pero con menos novedades por entrega facilita el diagnóstico posterior a la puesta en producción, explican, y confían en que mejoras recientes en sus procesos de desarrollo mantendrán la fiabilidad del navegador. Esta estrategia no es nueva en el mundo del software: muchas organizaciones prefieren lanzamientos incrementales y continuos para minimizar el riesgo asociado a grandes saltos funcionales.
Para los usuarios finales, el cambio será, en general, poco traumático: las actualizaciones de Chrome siguen instalándose en segundo plano, pero es probable que aparezcan avisos de reinicio con más periodicidad. Si eres de los que rara vez cierra el navegador, notarás más reicnios necesarios para aplicar las nuevas versiones. Para las empresas y equipos de TI la buena noticia es que la opción Extended Stable sigue disponible para quienes necesitan plazos más largos para pruebas y certificaciones; la guía de administración y políticas de despliegue de Chrome Enterprise es un recurso útil para planificar este tipo de cambios: support.google.com/chrome/a/answer/7679408.

En materia de seguridad, Google mantiene la política de parches frecuente: aunque las correcciones de seguridad se agrupan en los hitos de lanzamiento, el modelo actual establece actualizaciones semanales para reducir la llamada “ventana de parcheo” (patch gap) y así limitar el tiempo que los atacantes tienen para aprovechar vulnerabilidades publicadas. Esta atención constante a los parches es crítica si se tiene en cuenta el historial reciente de vulnerabilidades explotadas en Chrome; por eso es importante mantener las actualizaciones automáticas activadas y aplicar los reinicios cuando se solicite. El histórico de avisos y parches se puede consultar en el blog oficial de Chrome Releases: chromereleases.googleblog.com.
Para desarrolladores de extensiones, integraciones y responsables de calidad, el nuevo ritmo implica ajustar pruebas y procesos de lanzamiento. Con entregas más frecuentes hay menos tiempo para validar y más necesidad de automatización en las pruebas, por lo que los equipos deberán adaptar su integración continua y supervisión para detectar regresiones rápidamente. Al mismo tiempo, la posibilidad de revertir o emitir correcciones menores con mayor agilidad puede ser un alivio cuando aparece un fallo en producción.
En resumen, la transición a un ciclo de dos semanas pretende combinar la velocidad de entrega con la reducción del impacto por cada actualización. Google apuesta por una estrategia de cambios incrementales y parches continuos que, si se acompaña de buenas prácticas de gestión de versiones y pruebas automatizadas, puede mejorar la experiencia de usuarios y administradores. Si quieres seguir la evolución de estos cambios y leer los comunicados oficiales, las fuentes primarias son el blog de Chromium y el canal de Chrome Releases; para contexto histórico sobre cómo ha ido variando la cadencia de Chrome en años anteriores, medios tecnológicos como The Verge cubrieron el anterior ajuste de 2021 cuando el ciclo se aceleró a cuatro semanas: The Verge — cambio a ciclo de cuatro semanas.
Relacionadas
Mas noticias del mismo tema.

RAMPART y Clarity redefinen la seguridad de los agentes de IA con pruebas reproducibles y gobernanza desde el inicio
Microsoft ha presentado dos herramientas de código abierto, RAMPART y Clarity, orientadas a cambiar la manera en que se prueba la seguridad de los agentes de IA: una que automat...

Un único token de workflow de GitHub abrió la puerta a la cadena de suministro de software
Un único token de workflow de GitHub falló en la rotación y abrió la puerta. Esa es la conclusión central del incidente en Grafana Labs tras la reciente oleada de paquetes malic...

Webworm 2025: el malware que se esconde en Discord y Microsoft Graph para evadir la detección
Las últimas observaciones de investigadores en ciberseguridad señalan un cambio de tácticas preocupante de un actor vinculado a China conocido como Webworm: en 2025 ha incorpora...

La identidad ya no basta: la verificación continua del dispositivo para una seguridad en tiempo real
La identidad sigue siendo la columna vertebral de muchas arquitecturas de seguridad, pero hoy esa columna está agrietándose bajo nuevas presiones: phishing avanzado, kits que pr...

La materia oscura de la identidad está cambiando las reglas de la seguridad corporativa
El informe Identity Gap: Snapshot 2026 publicado por Orchid Security pone números a una tendencia peligrosa: la "materia oscura" de identidad —cuentas y credenciales que no se v...

PinTheft el exploit público que podría darte root en Arch Linux
Un nuevo exploit público ha llevado a la superficie otra vez la fragilidad del modelo de privilegios en Linux: el equipo de V12 Security bautizó la falla como PinTheft y publicó...

YellowKey El fallo de BitLocker que podría permitir a un atacante desbloquear tu unidad con solo acceso físico
Microsoft ha publicado una mitigación para una vulnerabilidad de omisión de seguridad de BitLocker conocida como YellowKey (CVE-2026-45585), después de que su prueba de concepto...