Bonjour,
Voici l’idée qui revient sans cesse : la majeure partie de la frustration liée au « nouvelle version disponible à chaque commit » vient du fait que le canal latest se met à jour en continu, donc être en retard de quelques commits est en réalité l’état de repos normal, mais la page le traite comme s’il y avait un problème. Plutôt que de tout repenser, je proposerais de mieux distinguer le signal du bruit.
Concrètement, la page aurait un seul bandeau d’état dont la signification changerait selon votre situation réelle :
- À jour → discret, positif, aucune action requise.
- Quelques commits derrière
latest→ gris/informatif, avec une mention explicite aucune action requise. C’est l’état qui crie actuellement, alors qu’il ne devrait pas. - Une nouvelle version mensuelle arrive (ex.
v2026.8.0) → bien visible, avec un lien vers les notes de version. - Mise à jour de sécurité → rouge/urgent, mis en évidence à part.
Seuls les deux derniers cas devraient donner l’impression qu’une action est nécessaire.
Quelques autres éléments que j’aimerais y voir :
- Le numéro de version, bien en vue à nouveau. Juste une petite carte affichant la version installée, le hash du commit et le canal (ex.
v2026.8.0-latest.1 · dfe770d · latest). C’est la plainte la plus courante que j’ai vue, et c’est facile à réintégrer. - S’appuyer sur la vérification en cache que nous avons déjà. La vérification de version s’exécute déjà via un job Sidekiq périodique plutôt qu’en temps réel à chaque requête, donc la page n’a pas besoin de sembler lente : elle peut afficher immédiatement le résultat en cache avec une ligne « dernière vérification il y a X min » et un bouton « vérifier maintenant », au lieu de recalculer à chaque chargement.
- Un historique des mises à jour avec liens vers les changelogs, essentiellement l’idée originale de ce sujet. Une courte chronologie des versions (mensuelles + ESR), chacune liée à son changelog ou à ses différences.
Concernant les composants et les reconstructions : ce que je voudrais voir rendu le plus explicite possible, c’est la distinction entre les mises à jour que le metteur à jour web peut appliquer lui-même (noyau + plugins, via git pull) et celles qui modifient le conteneur et nécessitent donc ./launcher rebuild app en ligne de commande. Une liste par composant, où chaque ligne indique à quelle catégorie elle appartient, serait très utile ; pour les cas nécessitant une reconstruction, elle pourrait afficher la commande exacte avec un bouton de copie, plutôt que de laisser l’utilisateur deviner.
Concernant la compatibilité des plugins : le mécanisme .discourse-compatibility gère déjà le cas où votre noyau est plus ancien que ce qu’un plugin cible désormais : il récupète silencieusement le dernier commit compatible de ce plugin lors d’une reconstruction. Cela concerne surtout les installations stables/ESR, et aujourd’hui cela se fait en silence. Ce serait bien de l’afficher comme une ligne informative « maintenu à une version compatible » afin que les administrateurs utilisant des versions anciennes puissent comprendre pourquoi un plugin n’est pas à son dernier commit. (Le cas inverse, un plugin ne supportant pas encore un noyau plus récent, n’est pas vraiment géré aujourd’hui ; une demande de fonctionnalité ouverte sur les versions compatibles min/max couvrirait ce point.)
J’ai rapidement monté un mock interactif pour voir comment les différents états se comparent côte à côte — honnêtement, le plus grand gain vient simplement de l’état « vous êtes en retard, mais ce n’est pas grave ». Une fois que cela ne déclenche plus d’alarme, la page redevient vraiment utile. Je peux partager le mock si quelqu’un souhaite l’explorer.