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:
- Al día → discreto, positivo, sin llamada a la acción.
- Unos commits por detrás de
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. - Se aproxima un nuevo lanzamiento mensual (por ejemplo,
v2026.8.0) → destacado, con un enlace a las notas de lanzamiento. - Actualización de seguridad → rojo/urgente, destacado por separado.
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í:
- El número de versión, de nuevo bien visible. Solo una pequeña tarjeta con la versión instalada, el hash del commit y el canal (por ejemplo,
v2026.8.0-latest.1 · dfe770d · latest). Esa es la queja más común que he visto y es fácil de recuperar. - Aprovechar la verificación en caché que ya tenemos. La verificación de versión ya se ejecuta como un trabajo periódico de Sidekiq en lugar de en tiempo real por solicitud, por lo que la página no debería sentirse lenta; puede renderizar ese resultado en caché inmediatamente con una línea “última verificación hace X minutos” y un botón manual “verificar ahora”, en lugar de parecer que se vuelve a calcular al cargar.
- Un historial de actualizaciones con enlaces al registro de cambios, básicamente la idea original en este tema. Una línea de tiempo corta de lanzamientos (mensuales + ESR), cada uno con enlace a su registro de cambios o diff.
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.