Para más información sobre todos los cambios lanzados en 2026.1, consulta:
Este es el primer lanzamiento “ESR” (soporte de mantenimiento a largo plazo) de Discourse, y reemplaza la antigua rama “stable” (estable). Los sitios que sigan la rama estable se actualizarán de 3.5 a 2026.1 en su próxima actualización. Para ver todos los cambios de 3.5 a 2026.1, usa este enlace.
También se han lanzado lanzamientos de parche para otras versiones compatibles:
2026.1.0 también será la primera versión esr (soporte de mantenimiento a largo plazo).
Para las personas en la rama estable existente anteriormente (que ahora está aliada a esr), pasarán de 3.5.3 a 2026.1.0; y no a 3.5.4.
Entonces déjame ver, tengo hasta abril para no actualizar (3 meses) cuando v2026.1 sea obsoleto, mi versión actual será ESR, ¿verdad? Todos estos cambios son un poco confusos.
Sí, a menos que estén usando la etiqueta v3.5.4 para mantenerse en 3.5.
El diagrama en la página de inicio de https://releases.discourse.org/ es la mejor manera de visualizar las cosas.
Independientemente de la rama de lanzamiento que elija, siempre deberá actualizarse periódicamente para obtener correcciones de seguridad críticas. La pregunta es si también desea incorporar nuevas características y otros cambios junto con las correcciones de seguridad (si es así, use release o latest), o si prefiere tener una cadencia de aproximadamente 6 meses para ellos (si es así, use esr).
Todavía estamos en las primeras etapas de este nuevo esquema de numeración, por lo que la documentación y las herramientas seguirán evolucionando a medida que crezcamos en el nuevo sistema.
La última vez que actualicé fue la v2026.0 en diciembre y ahora la v2026.2, se convertirá en ESR en abril, ¿verdad?
Consulte la página de inicio de releases.discourse.org para obtener toda la información de soporte. 2026.1 es la versión de soporte extendido actual y será compatible hasta octubre de 2026.
2026.2 se lanzará en febrero y recibirá correcciones de seguridad durante 2 meses después de eso. No será una versión de soporte extendido.
¿Es 2026.1.0 la primera versión estable/ESR en eliminar el soporte para iOS y otros navegadores antiguos? Es un cambio lo suficientemente grande como para que deba figurar en las notas de la versión. Sin embargo, no pude encontrar nada al respecto en el cuadro de búsqueda de “cambios detallados” al final.
Oh, creo que es porque has enlazado al registro de cambios de v2026.1.0-latest → v2026.1.0. Si lo cambias a v3.5.3 → v2026.1.0 entonces muestra 2397 cambios detallados, en lugar de solo 369. Para estas versiones ESR realmente deberías enlazar a la última versión ESR en lugar de a -latest (¿es eso como una RC?).
Aún no puedo ver qué cambio marcó claramente la eliminación del soporte para los navegadores antiguos, pero al menos pude encontrar este: FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub
Sí 
Sí. La gran mayoría de la gente usa las ramas latest o release de Discourse, por lo que el sitio del registro de cambios está optimizado para eso. Las personas que eligen ESR esencialmente están ‘saltándose 5 versiones’ cada vez que actualizan, por lo que tendrías que ver los cambios de cada una de esas versiones intermedias.
Puedes hacerlo navegando por cada registro de cambios intermedio, o puedes usar los filtros para generar un registro de cambios personalizado que abarque todo el rango (como has hecho). Quizás podamos mejorar la experiencia de usuario del sitio de lanzamientos para tener algún tipo de enlace rápido para saltar a una comparación ESR → ESR.
Mirando hacia atrás al último lanzamiento ‘estable’, tampoco teníamos un ‘mega-registro de cambios’ para eso. La gente tenía que leer cada uno de los registros de cambios beta intermedios para obtener una imagen completa de los cambios. Así que creo que vamos en la dirección correcta aquí; al menos ahora es posible ver un registro de cambios completo, aunque la experiencia de usuario no sea la más fluida.
Por ahora, he añadido un enlace a esa comparación ESR → ESR en la publicación original aquí:
¡Gracias por los comentarios!
Si un cambio entre los commits x e y, ya sea de una versión concreta a otra o desde un punto arbitrario en latest hasta el latest más reciente, no se puede aplicar mediante el actualizador integrado y, en su lugar, requiere que el contenedor se reconstruya a partir de una nueva imagen, ¿el nuevo sistema de notas de la versión lo identificará y tomará nota de la necesidad de una reconstrucción?
Por separado, ¿el actualizador integrado impedirá la actualización, solicitando una reconstrucción?
Mi entendimiento superficial del actualizador integrado es que después de actualizar Docker_manager, bloqueará la actualización de Discourse si se requiere una reconstrucción. Sin embargo, no he visto esto formalizado y, anecdóticamente, no ha parecido completamente fiable.
Específicamente, a veces, al navegar desde la actualización completada de Docker_manager a la página de Versiones, la actualización de Discourse estará disponible para comenzar, y solo después de actualizar la página se bloqueará. [Observaré que la última vez que vi que eso sucediera fue hace bastante tiempo, tal vez se haya solucionado.]
La necesidad de una reconstrucción está relacionada con la ‘imagen base de Docker’ de Discourse, que está totalmente desacoplada del número de versión de Discourse. La requerimos cuando hay cambios críticos en las dependencias a nivel de sistema operativo dentro de la imagen de docker.
Por lo tanto, sería complicado incluirlo en las notas de la versión principal de Discourse. Pero entiendo tu punto sobre lo sorprendente/frustrante que es no poder actualizar desde la interfaz de usuario. Quizás podamos hacer mejoras en la interfaz de usuario en ese aspecto.
Me lo imagino funcionando de la siguiente manera:
Dicho esto, todavía tenemos otros asuntos más importantes que atender ahora y que son más importantes para el trabajo de versionado en general (por ejemplo, la compatibilidad con componentes temáticos/plugins).
Oh, creo que no siempre poder usar la interfaz de usuario para actualizar está bien y cualquiera (individuo, negocio, lo que sea) que aloje Discourse por su cuenta debe (debería) tener a alguien disponible con al menos habilidades básicas de administración de servidores para poder realizar tareas como mantener actualizado el sistema anfitrión y reconstruir Discourse.
Lo más importante en mi opinión es:
Mientras la interfaz de usuario siempre se actualice correctamente después de actualizar Docker_manager, es decir, que no se pueda terminar en un estado donde sabe que Docker_manager está actualizado pero no sabe que se requiere una reconstrucción, creo que ambas cosas ya son ciertas.