En pocas palabras: Anne McCarthy, release lead de WordPress 7.1, publicó un decision log donde revela que la versión salió sin coordinación en la WordCamp US 2026 de Phoenix: un commit disparó las auto-updates cerca de las 13:30 MT y ya se había descargado 300.000 veces antes del acto en el escenario.
El lanzamiento de WordPress 7.1 en la WordCamp US 2026 de Phoenix fue un caos: la auto-actualización se disparó sola cerca de las 13:30 (hora de montaña), la versión se descargó 300.000 veces antes del acto en el escenario, y Anne McCarthy, la release lead, decidió publicar igual sin esperar a Matt Mullenweg. Después contó todo en un decision log.
Un decision log es un registro público donde el líder de una versión de WordPress documenta cada decisión importante tomada durante el ciclo de release: qué se incluyó, qué se pospuso y por qué. El de WordPress 7.1 lo escribió Anne McCarthy, release lead de esa versión, y lo publicó para dejar un rastro que futuros líderes puedan consultar.
En 30 segundos
- Qué pasó: el lanzamiento en vivo de WordPress 7.1 en WCUS 2026 (Phoenix) se descoordinó y la versión salió antes del acto ceremonial.
- El error técnico: un commit disparó las auto-updates a eso de las 13:30 MT, cuando 7.1 solo debía estar en la página de Downloads y por WP-CLI.
- El número: 300.000 descargas antes de que Mullenweg solo pareciera notar que el release estaba en marcha.
- La falla en cascada: Austin Ginder, fundador de Anchor Hosting, marcó un fatal error con WP Rocket en X antes del acto.
- El patrón: es el segundo lanzamiento en vivo del año que sale mal (WordPress 7.0 ya se había pospuesto antes de WordCamp Asia).
WordPress es un sistema de gestión de contenidos de código abierto creado por Matt Mullenweg en 2003, desarrollado por la WordPress Foundation y la comunidad global. Permite crear y administrar sitios web, blogs y tiendas online.
¿Qué es el decision log de Anne McCarthy y por qué lo publicó?
El decision log es la bitácora completa de decisiones del ciclo de WordPress 7.1, desde el roadmap hasta el día del release. McCarthy lo publicó para dejar documentado el «por qué» de cada llamada, algo que el rol de release lead nunca había tenido antes. La idea: que el próximo que agarre el fierro caliente no arranque de cero.
«Los releases son un torbellino y muchas veces me encuentro rascándome la cabeza tratando de recordar: ¿por qué hicimos X y no Y?», escribió McCarthy en el registro que reportó The Repository. Ese es el problema que intenta resolver el documento.
Un detalle jugoso para cualquiera que trabaje con IA: McCarthy usó inteligencia artificial para elaborar el log a partir de mensajes de Slack, actividad de GitHub y Trac. ¿Y funcionó? No tanto. Ella misma calificó los «briefings» de IA como «a bust» (un fiasco). O sea que hasta la persona que lideró el release terminó reconstruyendo varias decisiones de memoria, y avisó que probablemente actualice el post a medida que se acuerde de más cosas. Tema relacionado: cómo evolucionan los themes y builders.
¿Qué salió mal en el lanzamiento de WordPress 7.1 en WCUS 2026?
Falló la coordinación de punta a punta. Ni McCarthy ni el conductor del evento, Robert Jacobi, habían visto las slides antes de subir al escenario (algo que el propio Mullenweg blanqueó cuando arrancó su sesión). El plan original era que Mullenweg recibiera la proclamación de la ciudad de Phoenix, pasara las slides con el video de highlights de 7.1 y de ahí abriera su sesión de cierre. No pasó así.
Ponele que estás detrás del telón esperando la señal para lanzar, y en el medio te llega el mensaje de que el fundador «no quiere apretar el botón», el release ya se descargó 300.000 veces por su cuenta, alguien acaba de tuitear que un plugin popular tira un fatal error, y vos tenés que decidir en segundos si publicás o frenás todo delante de una sala llena. Ese fue el escenario real.
McCarthy terminó siendo llamada al escenario unas 50 minutos después de lo planeado. Según reportó The Repository, Mullenweg solo pareció notar que el lanzamiento estaba en marcha recién después de las 300.000 descargas y después de que Austin Ginder marcara el problema de WP Rocket en X.
¿Por qué la auto-update de WordPress 7.1 se activó temprano?
Un commit disparó las actualizaciones automáticas antes de tiempo, cerca de las 13:30 MT, cuando WordPress 7.1 solo debía estar disponible por la página de Downloads y vía WP-CLI. Ese adelanto hizo que cientos de miles de sitios empezaran a bajar la versión antes del acto ceremonial, sin la sincronización que el evento en vivo suponía. Esto se conecta con lo que analizamos en dinámicas de la comunidad WordPress.
El tema es que cuando la auto-update se enciende, no espera a nadie. Si tu sitio tiene actualizaciones automáticas de core activadas (algo por defecto en muchas instalaciones), la versión te llega y punto. Y si un plugin de peso todavía no era compatible, ahí aparece el fatal error del que hablaba Ginder.
¿Qué fue lo del «botón» con Matt Mullenweg?
Entre bastidores llegó el mensaje de que Mullenweg «doesn’t want to do the button» («no quiere hacer el botón»), y McCarthy lo describió como ambiguo. Podía significar dos cosas: que no quería apretar un botón ceremonial de utilería para lanzar él mismo el release, o que directamente no quería hacer el lanzamiento en vivo en el escenario. Nadie lo tenía claro en el momento.
Ante la duda, McCarthy tomó la decisión de publicar y listó siete razones en el post. La primera: no querer empujar contra Mullenweg en medio de su presentación. Lo interesante es cómo cerró esa parte.
«Voy a hacerme cargo de esta decisión si más adelante resulta equivocada», escribió. Poca gente en un rol de coordinación firma así de claro una decisión tomada bajo presión y con información incompleta. Ojo con esto, porque marca el tono de todo el documento: transparencia hasta cuando incomoda. Complementá con nuevas herramientas para crear contenido.
¿Qué funciones se pospusieron en WordPress 7.1?
Varias, y algunas conocidas. El decision log documenta que la colaboración en tiempo real (real-time collaboration) volvió a quedar afuera tras confirmar con Mullenweg y el lead architect Matías Ventura que no estaba lista. También hubo idas y vueltas con el editor y con dependencias clave.
- Real-time collaboration, pospuesta: la edición colaborativa en vivo se pateó de nuevo por no estar madura, confirmado con Ventura.
- Classic block, reversión de plan: se dio marcha atrás con la idea de esconder el bloque Clásico del inserter.
- React 19, diferido: se corrió por problemas de compatibilidad hacia atrás que aparecieron durante el ciclo.
- Merges Knowledge y Guidelines, vetados: McCarthy trasladó el veto de Mullenweg a esas dos propuestas de merge.
McCarthy había definido su enfoque para 7.1 como «bajarle la temperatura después de 7.0», priorizando previsibilidad y adelantar decisiones. En papel, el criterio se cumplió. El acto en vivo, otra historia.
¿Por qué WordPress lanza releases en vivo en eventos (y le sale mal)?
El modelo de «lanzar en el evento» lo propuso el core committer Jonathan Desrosiers en diciembre de 2025, después del lanzamiento exitoso de WordPress 6.9 durante el State of the Word. La idea era atar los tres releases mayores de 2026 a eventos insignia. El problema es que dos de tres no salieron como esperaban.
| Release 2026 | Evento | Resultado |
|---|---|---|
| WordPress 7.0 | WordCamp Asia (Mumbai) | Pospuesto por problemas con la colaboración en tiempo real; se cambió por un panel |
| WordPress 7.1 | WordCamp US (Phoenix) | Salió temprano por auto-update; acto descoordinado, 300.000 descargas antes del escenario |
| WordPress 7.2 | State of the Word | Apuntado al 9 de diciembre de 2026 (pendiente) |
¿Sirve atar un release técnico a un show en vivo? Todavía no está claro. El único que salió redondo fue el 6.9 en el State of the Word, que fue justamente el que inspiró el modelo. Los dos siguientes mostraron que un cronograma de software y un guion de escenario no siempre coinciden. En ambiente seguro para probar cambios profundizamos sobre esto.
¿Cómo te impacta este lío si administrás WordPress en Argentina?
Si tenés sitios en producción, el aprendizaje concreto de este episodio es uno: nunca dejes que una versión mayor entre sola el día del lanzamiento. El caso del fatal error con WP Rocket en 7.1 muestra cómo una incompatibilidad de plugin te puede tumbar el sitio apenas se dispara la auto-update, sin que vos toques nada. Más sobre esto en vulnerabilidades en plugins de terceros.
- Frená las auto-updates de core mayores: dejá las menores (de seguridad) activas, pero controlá vos cuándo pasás de 7.0 a 7.1.
- Probá en staging primero: subí la versión a un entorno de prueba, revisá tus plugins críticos y recién después llevala a producción. Con un hosting WordPress como el de Donweb podés armar un staging sin dramas.
- Esperá unos días tras un release mayor: que los plugins pesados (page builders, cache, WooCommerce) confirmen compatibilidad antes de actualizar.
- Backup antes de tocar nada: obvio, pero es lo que la gente saltea justo el día que se rompe algo.
Sobre los parches de seguridad de las versiones 7.x (el tema de vulnerabilidades y CVEs) no me meto acá, porque es terreno del blog hermano. Si te interesa el detalle de hardening y parches, mirá seguridadenwordpress.com.
Qué está confirmado y qué no
- Confirmado: McCarthy publicó el decision log y documentó las decisiones del ciclo.
- Confirmado: la auto-update se disparó cerca de las 13:30 MT y hubo 300.000 descargas antes del acto ceremonial.
- Confirmado: real-time collaboration, React 19 y los merges de Knowledge/Guidelines quedaron fuera de 7.1.
- Confirmado: WordPress 7.2 está apuntado al 9 de diciembre de 2026 en el State of the Word.
- Sin confirmar: qué quiso decir Mullenweg con «no quiere hacer el botón»; McCarthy lo describió como ambiguo.
- Sin confirmar: si el modelo de release en vivo sigue igual o se ajusta para 7.2.
Errores comunes al actualizar en una situación así
- Dejar las auto-updates mayores en automático: te llega la versión el día del release y no controlás el timing. Corrección: pasá a control manual las actualizaciones de core mayores.
- Actualizar el mismo día del lanzamiento: es cuando más plugins todavía no están al día. Corrección: esperá el reporte de compatibilidad de tus plugins clave.
- Confiar en que «si salió, está estable»: el propio caso 7.1 muestra que salir y estar coordinado no es lo mismo. Corrección: staging y backup, siempre, antes de tocar producción.
Preguntas Frecuentes
¿Cuándo se lanzó WordPress 7.1?
WordPress 7.1 se lanzó durante la WordCamp US 2026 en Phoenix. La versión empezó a distribuirse antes del acto ceremonial porque un commit disparó las auto-updates cerca de las 13:30 (hora de montaña).
¿Qué es un decision log en WordPress?
Un decision log es un registro público donde el release lead documenta las decisiones tomadas durante el ciclo de una versión, con el porqué de cada una. El de WordPress 7.1 lo escribió Anne McCarthy y es el primero pensado como rastro para futuros líderes del proyecto.
¿Cuál fue el problema de WP Rocket con WordPress 7.1?
Austin Ginder, fundador de Anchor Hosting, marcó en X un fatal error asociado a WP Rocket cuando 7.1 empezó a descargarse. El adelanto de la auto-update dejó a algunos sitios actualizando el core antes de que ciertos plugins confirmaran compatibilidad plena.
¿En qué se diferencia WordPress 7.1 de 7.0?
McCarthy planteó 7.1 como una versión para «bajarle la temperatura» tras el 7.0, priorizando previsibilidad. En lo funcional, 7.1 volvió a posponer la colaboración en tiempo real y difirió React 19 por compatibilidad hacia atrás, dos frentes que ya venían del ciclo anterior.
¿Cuándo sale WordPress 7.2?
WordPress 7.2 está apuntado al 9 de diciembre de 2026, durante el State of the Word de este año. Sería el tercero de los releases mayores de 2026 atados a un evento insignia bajo el modelo propuesto en diciembre de 2025.
Conclusión
El decision log de McCarthy es, en el fondo, un gesto de madurez para un proyecto que suele decidir a puertas cerradas: dejar por escrito el porqué de cada llamada, incluso las que salieron mal. El lanzamiento de WordPress 7.1 se descoordinó por una auto-update adelantada y una comunicación floja backstage, no por una falla del código en sí.
Para vos, que administrás sitios, la lección es práctica y aburrida (las mejores suelen serlo): controlá manualmente las versiones mayores, probá en staging y no actualices el mismo día del bombo. Y si sos de los que miran el ecosistema, quedate atento al 9 de diciembre: si el 7.2 también se traba en vivo, va a ser difícil defender el modelo de lanzar releases arriba de un escenario.
