WordPress 6.8 va a ser la última versión por una temporada… al menos hasta la llegada de 2026, con lo que parece un ciclo anual de lanzamientos.
Recuerda que puedes escuchar este programa desde Pocket Casts, Spotify y Apple Podcasts o suscribirte al feed directamente.
Transcripción del programa
Hola, soy Javier Casares y estás escuchando WPpodcast, en el resumen de noticias de la Comunidad WordPress.
En este episodio encontrarás la información del 31 de marzo al 6 de abril de 2025.
El pasado 27 de marzo hubo una reunión de 30 personas que contribuyen y gestionan el proyecto de código abierto WordPress en el que se destacó que en los últimos 6 meses, los tickets de Gutenberg y el núcleo de WordPress es plano, aunque el trabajo de cierre ha caído desde el lanzamiento de WordPress 6.7, a finales de 2024.
Esto llevó a enfocar la reunión a si se debería reducir el lanzamiento de versiones de WordPress de, habitualmente, 3 versiones anuales, a solo 1.
En el artículo se hace referencia a algunos elementos a favor y en contra de este cambio, aunque en estos días en los que hay tanto ruido y noticias falsas, hay que trabajar en la verificación de datos para ver claramente que la mayoría de las ventajas que se exponen no son ciertas.
Con respecto a la reducción de carga y coordinación, es cierto que una reducción del ritmo de lanzamientos aliviaría la presión actual que existe sobre colaboradores y equipos, algo especialmente relevante en un momento donde la disponibilidad y las horas patrocinadas han disminuido significativamente.
Sobre que permite mejorar documentación e infraestructura, este punto es realista, ya que uno de los desafíos actuales es precisamente la documentación incompleta y la infraestructura desactualizada, algo que una desaceleración claramente podría mejorar.
Sobre la mayor automatización de procesos, es plausible y lógico que una menor presión permita invertir tiempo en la automatización, una necesidad ya expresada por el equipo central en diversas ocasiones recientes. Aunque, hay que tener en cuenta que las que pueden realizar estas tareas son las personas de Automattic que ahora mismo no contribuyen al proyecto.
Aun así, la ansiedad frente a lanzamientos más grandes sí que se ajusta a la realidad, especialmente ante una comunidad que se ha acostumbrado a cambios pequeños y frecuentes, donde modificaciones sustanciales pueden provocar preocupaciones sobre compatibilidad y estabilidad.
Sobre que permitiría incluir características más grandes, evitando versiones solo con correcciones, es técnicamente cierto, pero la disminución reciente en contribuciones, producto en parte del conflicto legal entre Automattic y WP Engine y sus efectos secundarios, podría hacer que, en la práctica, lograr grandes lanzamientos resulte complicado debido a falta de recursos.
Se comenta sobre la alineación con el ritmo de organizaciones como eBay o Airbnb, y, aunque algunas grandes empresas adoptan ciclos lentos por calidad, el contexto de WordPress, un proyecto comunitario abierto, no es completamente comparable con compañías privadas grandes.
Un foco principal sería centrarse en plugins canónicos y componentes individuales que si bien esto es positivo, no necesariamente garantiza éxito, ya que dependería enormemente de cómo se organice el proyecto y del soporte real que reciba cada componente o plugin en tiempos de crisis como la actual.
Sobre que menos lanzamientos pueden ralentizar la retroalimentación, aunque esto es teóricamente cierto, la realidad reciente muestra que ya existe lentitud en los ciclos de feedback debido a la disminución de contribuciones, independientemente del ritmo de lanzamientos.
Habría una mayor dificultad para justificar tiempo y recursos patrocinados, algo que es parcialmente falso, ya que actualmente existe dificultad para justificar patrocinios, y es probable que esta situación empeore aún más si la percepción es que el proyecto pierde velocidad o relevancia debido a conflictos internos.
Y sobre que habrá menos impulso visible hacia los objetivos del proyecto, es algo que ya está ocurriendo actualmente. La reducción en contribuciones y la batalla legal en curso han afectado la percepción externa del proyecto, por lo que el problema real ya existe, independientemente de si se adopta o no un ciclo más lento.
Tras las conversaciones mantenidas, se ha decidido que WordPress 6.8 será la última versión principal de WordPress durante el año 2025. Aunque ya no habrá grandes lanzamientos hasta 2026, el plugin Gutenberg seguirá recibiendo actualizaciones menores cada dos semanas, como ocurre actualmente, lo que dejaría entrever que si se quieren mejoras en el editor, tanto del Sitio como de Contenidos, habrá que instalarlo para poder mejorar la edición.
Además, se seguirán publicando versiones menores de WordPress durante el resto del año, las cuales incluirán pequeñas mejoras y correcciones necesarias, pero manteniendo la regla actual de no añadir nuevos archivos en estas versiones menores.
Con respecto a los plugins oficiales, canonical plugins, mantenidos por la comunidad, como los idiomas preferidos, autenticación en dos factores (2FA) y plugins relacionados con rendimiento, permiten incorporar y actualizar funcionalidades sin depender del lanzamiento principal anual. Se identificaron dos áreas clave para mejorar, como la recopilación efectiva de feedback buscando nuevas formas de recoger comentarios más significativos que la simple métrica de instalaciones activas, posiblemente incluyendo telemetría para entender mejor el uso y valor percibido por los usuarios, algo que habrá que ver con detalle, ya que podría incumplir ciertas normativas internacionales, como el RGPD. Esto iría acompañado de una mejor promoción y visibilidad de estos plugins, ya sea mediante entradas en el blog oficial, menciones en eventos importantes (como State of the Word), o mejor aprovechamiento de espacios infrautilizados en el panel de administración, como la sección “Herramientas”.
Otro trabajo importante, del que se lleva hablando muchos años, es la necesidad urgente de mejorar la gestión del enorme backlog actual con más de 12.000 tickets, pasando la mayoría de ellos a lanzamientos menores, independientemente del ciclo principal. También se plantea cerrar o posponer tickets antiguos o irrelevantes usando la resolución “maybelater”, algo que previamente ha generado debate en cuanto a quién decide lo que es importante o no en el proyecto. Así que, como un backlog grande afecta negativamente a la percepción externa de calidad y mantenibilidad del proyecto, se buscará reducir esta percepción mediante una gestión más eficiente.
Además, se mencionaron áreas diversas a mejorar para fortalecer el desarrollo y mantenimiento del proyecto, como un mayor énfasis en pruebas, promoviendo el uso extendido de versiones beta y nocturnas mediante iniciativas educativas y colaboraciones específicas con proveedores de hosting.
Revisar el flujo entre repositorios SVN/GitHub, para explorar maneras de simplificar y optimizar los procesos actuales de lanzamiento del núcleo y Gutenberg, que podría llevar a reducir el lanzamiento de actualizaciones del plugin Gutenberg a una vez al mes si el volumen de cambios continúa siendo reducido.
Clarificar la responsabilidad de los mantenedores y dar mayor autonomía a los equipos y componentes, pudiendo definir las expectativas para voluntarios responsables de componentes, motivándolos a una participación más consistente, y hacer que los Release Squads actúen como facilitadores, impulsando una mayor autonomía y participación activa de los equipos y componentes individuales del proyecto.
Con respecto a la accesibilidad y otros estándares y regulaciones, es necesario aclarar cuáles son los requisitos obligatorios de accesibilidad y qué prácticas adicionales son deseables pero no bloqueantes.
Y finalmente, involucrar más perfiles no técnicos, que en los últimos meses han salido de la comunidad, por vías adicionales para involucrar activamente a colaboradores con perfiles distintos al desarrollo, como diseño, testing o producto.
Sin duda, un momento interesante e importante para el proyecto, mientras que fuera de los cauces oficiales se preparan alternativas a la gobernanza del proyecto, ahora que parece que, desde la salida de la antigua dirección ejecutiva del proyecto, no hay una hoja de ruta definida.
Y con la segunda versión candidata de WordPress 6.8, y a falta de la tercera, el 15 de abril se lanzará la versión final de esta nueva rama de WordPress que parece que durará unos cuantos meses.
Y en el resumen mensual de Core, podemos ver cómo India y los países asiáticos siguen creciendo en cuanto a contribuciones al núcleo de WordPress, mientras otros, como Estados Unidos, siguen bajando.
En esta ocasión, en la recta final del lanzamiento de una nueva versión, que suelen incrementarse las contribuciones, en marzo se han reducido a menos de 200 las personas que han contribuido aunque se hayan incrementado los tickets abiertos.
El equipo de Comunidad ha anunciado una actualización que permite otorgar insignias en los perfiles a los voluntarios que colaboran en eventos WordCamp. Estas insignias buscan reconocer públicamente la importancia del trabajo voluntario, destacando a quienes contribuyen a la organización de estas conferencias globales sobre WordPress.
Anteriormente, solo los organizadores y ponentes recibían insignias en sus perfiles, pero ahora los voluntarios también podrán mostrar este reconocimiento oficial. Las insignias serán asignadas por los organizadores de cada WordCamp a través del sitio específico del evento.
La WordCamp Europe 2025 se acerca y ya está disponible el programa, que, como en años anteriores, tendrá un primer día de Contributor Day y posteriormente los dos días de charlas y talleres.
Los temas específicos de la Unión Europea, sobre accesibilidad y ciberseguridad, destacan en el programa, formado por 52 ponentes de 23 países.
Y, para acabar, este pódcast se distribuye con licencia Creative Commons; tienes todos los enlaces para ampliar la información, y el pódcast en otros idiomas, en WPpodcast .es.
Un abrazo, y hasta el próximo programa.
