Ciao,
Ecco l’idea a cui continuo a tornare: la maggior parte della frustrazione dovuta al “nuova versione disponibile ad ogni commit” deriva dal fatto che il canale latest si aggiorna continuamente, quindi essere in ritardo di qualche commit è in realtà lo stato di riposo normale, ma la pagina lo tratta come se ci fosse un problema. Quindi, invece di ridisegnare tutto, mi concentrerei sul distinguere il segnale dal rumore.
Come lo immagino io, la pagina ha un’unica barra di stato che cambia significato in base alla tua posizione effettiva:
- Aggiornato → silenzioso, positivo, senza call to action.
- Qualche commit indietro rispetto a
latest→ grigio/informativo, e dice esplicitamente nessuna azione richiesta. Questo è lo stato che attualmente “urla” e non dovrebbe farlo. - In arrivo un nuovo rilascio mensile (es.
v2026.8.0) → prominente, con un link alle note di rilascio. - Aggiornamento di sicurezza → rosso/urgente, evidenziato a parte.
Solo gli ultimi due dovrebbero sembrare qualcosa su cui devi agire.
Alcune altre cose che vorrei ci fossero:
- Il numero di versione, di nuovo in primo piano. Basta una piccola card con la versione installata, l’hash del commit e il canale (es.
v2026.8.0-latest.1 · dfe770d · latest). È la lamentela più comune che ho visto ed è facile da ripristinare. - Sfruttare il controllo in cache che già abbiamo. Il controllo della versione viene già eseguito come un lavoro Sidekiq periodico piuttosto che in tempo reale per ogni richiesta, quindi la pagina non dovrebbe sembrare lenta: può rendere il risultato in cache immediatamente con una riga “ultimo controllo X min fa” e un pulsante “controlla ora” manuale, invece di sembrare che stia ricalcolando al caricamento.
- Una cronologia degli aggiornamenti con link al changelog fondamentalmente l’idea originale in questo argomento. Una breve timeline dei rilasci (mensili + ESR) con link al relativo changelog o diff.
Sui componenti e rebuild: la cosa che vorrei vedere resa più esplicita è la distinzione tra gli aggiornamenti che l’aggiornatore web può applicare da solo (core + plugin, via git pull) e quelli che cambiano il container e quindi richiedono ./launcher rebuild app dalla riga di comando. Un elenco per componente in cui ogni riga mostra a quale categoria appartiene aiuterebbe molto, e per il caso rebuild potrebbe mostrare il comando esatto con un pulsante di copia invece di lasciarti indovinare.
Sulla compatibilità dei plugin: il meccanismo .discourse-compatibility gestisce già il caso in cui il tuo core è più vecchio di quello che un plugin ora richiede, controllando silenziosamente l’ultimo commit compatibile di quel plugin durante un rebuild. Questo riguarda principalmente le installazioni stable/ESR, e oggi avviene in silenzio. Sarebbe bello renderlo visibile come una riga informativa “mantenuto a una versione compatibile” così gli amministratori di rilasci più vecchi possono vedere perché un plugin non è sul suo commit più recente. (Il caso opposto, un plugin che non supporta ancora un core più nuovo, non è gestito oggi; c’è una richiesta di funzionalità aperta su versioni min/max compatibili che lo coprirebbe.)
Ho creato rapidamente un mockup interattivo per vedere come si presentano gli stati diversi affiancati: onestamente, il vantaggio maggiore è semplicemente lo stato “sei indietro ma va bene così”. Una volta che smette di essere un allarme, la pagina diventa nuovamente utile. Sono felice di condividere il mockup se qualcuno vuole esaminarlo.