Hemos estado barajando algunas ideas internamente sobre cómo mejorar la página de “actualización de Discourse”.
Una idea es mostrar el historial de actualizaciones, con enlaces a los registros de cambios para las diferencias entre ellas (lo cual podría ser útil para entender los cambios que observas después de realizar una actualización).
Aquí hay un par de otras ideas / quejas que acaban de surgir:
¿Qué otras ideas tienen la gente?
Hola,
Aquí está la idea a la que sigo volviendo: la mayor parte de la frustración por el “hay una nueva versión disponible en cada commit” proviene del hecho de que el canal latest se actualiza continuamente, por lo que estar unos commits por detrás es en realidad el estado de reposo normal, pero la página lo trata como si hubiera un problema. Así que, en lugar de rediseñar todo, me centraría en hacer que distinga entre señal y ruido.
Así lo veo: la página tiene un banner de estado que cambia de significado dependiendo de dónde estés realmente:
latest → gris/informativo, y dice explícitamente que no se requiere ninguna acción. Este es el estado que actualmente grita y realmente no debería.v2026.8.0) → destacado, con un enlace a las notas de lanzamiento.Solo los dos últimos deberían dar la sensación de que necesitas actuar.
Unas cuantas cosas más que me gustaría ver ahí:
v2026.8.0-latest.1 · dfe770d · latest). Esa es la queja más común que he visto y es fácil de recuperar.Sobre componentes y reconstrucciones: lo que más me gustaría que se hiciera explícito es la división entre las actualizaciones que el actualizador web puede aplicar por sí mismo (núcleo + plugins, mediante git pull) y las que cambian el contenedor y, por lo tanto, requieren ./launcher rebuild app desde la línea de comandos. Una lista por componente donde cada fila muestre a qué categoría pertenece ayudaría mucho, y para el caso de reconstrucción podría mostrar el comando exacto con un botón de copiar en lugar de dejarte adivinar.
Sobre la compatibilidad de plugins: el mecanismo .discourse-compatibility ya maneja el caso en el que tu núcleo es anterior al que apunta ahora un plugin; revisa silenciosamente el último commit compatible de ese plugin durante una reconstrucción. Esto afecta principalmente a las instalaciones estables/ESR, y hoy en día ocurre en silencio. Sería bueno mostrarlo como una línea informativa sencilla “mantenido en una versión compatible” para que los administradores de versiones antiguas puedan ver por qué un plugin no está en su último commit. (El caso opuesto, un plugin que aún no admite un núcleo más nuevo, no está realmente manejado hoy; hay una solicitud de función abierta sobre versiones mínimas/máximas compatibles que lo cubriría.)
Armé rápidamente un modelo interactivo para ver cómo se sienten los diferentes estados lado a lado; honestamente, la mayor ventaja es simplemente el estado “estás por detrás, pero está bien”. Una vez que eso deje de ser una alarma, la página vuelve a ser genuinamente útil. Me encantaría compartir el modelo si alguien quiere echarle un vistazo.
Muy buen contenido.
Solo una aclaración sobre esta parte:
Pienso que esto se referiría a las actualizaciones que tú hayas realizado, no necesariamente a los «lanzamientos» que nosotros hacemos.
Así, cada vez que realices una actualización, aparecerá una nueva fila. Podría corresponder a 5 confirmaciones dentro de un lanzamiento. O podría ser desde 2026.1.6 hasta 2026.7.1 si esperaste al primer lanzamiento de parches después del siguiente ESR para actualizar.
En cualquier caso, debería mostrarte el historial de las actualizaciones que tú realizaste en tu sitio anteriormente y el conjunto de cambios entre ellas.
¡Añade algo destacado sobre la importancia de hacer una copia de seguridad primero!
Añade algo sobre cómo, si la actualización falla, el siguiente paso es reconstruir el launcher desde la CLI. Al menos una nota indicando que las actualizaciones a veces fallan y que eso dejará el foro fuera de línea.
Idealmente, una forma de señalar que los cambios pendientes incluyen algo importante, como la actualización de la versión de la base de datos que ocurrió recientemente y que, la última vez que sucedió, fue realmente un evento mayor, en términos del número de temas iniciados aquí para soporte. Si mal no recuerdo.
Ah, esa es una mejor formulación que la mía, tienes razón. Había imaginado una lista de tus lanzamientos, pero un registro de las actualizaciones que este sitio web ha realizado realmente es más útil.
Cada línea representa, por tanto, un evento de actualización y muestra de dónde a dónde se ha pasado → y qué conjunto de cambios hubo en medio. Esto cubre, naturalmente, ambos casos: un pequeño aumento de versión dentro de un canal con un puñado de commits o un gran salto como v2026.1.6 → v2026.7.1, cuando alguien espera el primer parche de ESR después de que se haya publicado la siguiente versión ESR.
