Amélioration de la page « Mises à jour de Discourse »

Contribuer UX
1

Nous avons discuté en interne de plusieurs idées pour améliorer la page « mise à jour de Discourse ».

L’une des propositions consiste à afficher l’historique des mises à jour, avec des liens vers les journaux de modifications (changelogs) pour les différences entre chaque version (ce qui pourrait être utile pour comprendre les changements que vous observez après une mise à jour).

Voici quelques autres idées / remarques qui viennent de surgir :

Quelles sont les autres idées que vous avez ?

1 « J'aime »
2

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.

https://dynamic-changi-gne2.pagedrop.io/

1 « J'aime »
3

Bonne proposition.

Une seule précision concernant cette partie :

Je pense que cela concernerait les mises à jour que vous avez effectuées, et pas nécessairement les « versions » que nous publions.

Ainsi, à chaque fois que vous effectuez une mise à jour, une nouvelle ligne apparaît. Elle pourrait correspondre à 5 commits au sein d’une version. Ou bien elle pourrait refléter la transition de 2026.1.6 vers 2026.7.1 si vous avez attendu la première version correcte après la sortie de la prochaine ESR pour mettre à jour.

Dans tous les cas, cela devrait vous afficher l’historique des mises à jour que vous avez effectuées sur votre site, ainsi que les ensembles de modifications entre ces versions.

4

Ajoutez une mention bien visible sur l’importance de faire une sauvegarde en premier !

Ajoutez une note expliquant que, en cas d’échec de la mise à jour, l’étape suivante consiste à reconstruire le lanceur via l’interface en ligne de commande (CLI). Ajoutez au moins une remarque indiquant que les mises à jour échouent parfois, ce qui mettra le forum hors ligne.

Idéalement, un moyen de signaler que les modifications en attente incluent quelque chose de majeur, comme la mise à niveau de la version de la base de données qui a eu lieu récemment et qui a, la dernière fois, été un véritable événement majeur, en termes de nombre de sujets de support ouverts ici. Si je me souviens bien.