Pour plus d’informations sur tous les changements publiés dans la version 2026.1, consultez :
Ceci est la première version « ESR » (Extended Support Release) de Discourse, et elle remplace l’ancienne branche « stable ». Les sites qui suivent la branche stable seront mis à niveau de la version 3.5 à la version 2026.1 lors de leur prochaine mise à niveau. Pour voir tous les changements de la 3.5 à la 2026.1, utilisez ce lien.
Des versions de correctif pour les autres versions prises en charge ont également été publiées :
2026.1.0 étant également la première version esr (support à long terme).
Pour les personnes utilisant la branche stable précédemment existante (qui est maintenant aliasée en esr), la mise à jour se fera de 3.5.3 à 2026.1.0 ; et non à 3.5.4.
Laissez-moi voir, j’ai jusqu’en avril pour ne pas mettre à jour (3 mois) quand la v2026.1 sera dépréciée, ma version actuelle sera ESR, n’est-ce pas ? Tous ces changements sont un peu confus.
Quel que soit le flux de publication que vous choisissez, vous devrez toujours mettre à jour régulièrement pour les correctifs de sécurité critiques. La question est de savoir si vous souhaitez également intégrer de nouvelles fonctionnalités et d’autres changements avec les correctifs de sécurité (si oui, utilisez release ou latest), ou si vous préférez avoir une cadence d’environ 6 mois pour ceux-ci (si oui, utilisez esr).
Ce nouveau système de numérotation n’en est qu’à ses débuts, donc la documentation et les outils continueront d’évoluer à mesure que nous nous intégrerons au nouveau système.
Consultez la page d’accueil de releases.discourse.org pour toutes les informations de support. 2026.1 est la version de support étendu actuelle, et sera supportée jusqu’en octobre 2026.
2026.2 sera publiée en février et recevra des correctifs de sécurité pendant 2 mois après cela. Ce ne sera pas une version de support étendu.
Est-ce que 2026.1.0 est la première version stable/ESR à abandonner la prise en charge d’iOS et d’autres anciens navigateurs ? C’est un changement suffisamment important pour être mentionné quelque part dans les notes de version. Je n’ai rien trouvé à ce sujet dans la boîte de recherche des « changements détaillés » à la fin cependant.
Oh, je pense que c’est parce que vous avez lié au journal des modifications pour v2026.1.0-latest → v2026.1.0. Si vous le changez en v3.5.3 → v2026.1.0, cela montre 2397 changements détaillés, au lieu de seulement 369. Pour ces versions ESR, vous devriez vraiment lier à la dernière version ESR au lieu de -latest (est-ce comme une RC ?)
En effet. La grande majorité des utilisateurs utilisent les flux latest ou release de Discourse, c’est donc pour cela que le site du journal des modifications est optimisé. Les personnes qui choisissent ESR « sautent » essentiellement 5 versions à chaque mise à niveau, vous devez donc examiner les changements pour chacune de ces versions intermédiaires.
Vous pouvez le faire en parcourant chaque journal des modifications intermédiaire, ou vous pouvez utiliser les filtres pour générer un journal des modifications personnalisé couvrant toute la plage (comme vous l’avez fait). Peut-être pourrions-nous améliorer l’expérience utilisateur du site des versions pour avoir une sorte de lien rapide pour passer d’une comparaison ESR à ESR.
En regardant la dernière version « stable », nous n’avions pas non plus de « méga-journal des modifications » pour celle-ci. Les gens devaient lire chacun des journaux des modifications bêta intermédiaires pour avoir une image complète des changements. Je pense donc que nous allons dans la bonne direction ici - au moins, il est maintenant possible de voir un journal des modifications complet, même si l’expérience utilisateur n’est pas la plus fluide.
Pour l’instant, j’ai ajouté un lien vers cette comparaison ESR → ESR dans le message initial ici :
Que ce soit d’une version particulière à une autre ou d’un point arbitraire dans latest à la dernière version de latest, si un changement entre les commits x et y ne peut pas être appliqué par le programme de mise à jour intégré, nécessitant à la place que le conteneur soit reconstruit à partir d’une nouvelle image, le nouveau système de notes de version l’identifiera-t-il et notera-t-il la nécessité d’une reconstruction ?
Séparément, le programme de mise à jour intégré empêchera-t-il la mise à jour, demandant une reconstruction ?
Ma compréhension approximative du programme de mise à jour intégré est qu’après la mise à jour de Docker_manager, il bloquera la mise à jour de Discourse si une reconstruction est nécessaire. Je n’ai pas vu cela formalisé cependant et, d’après mon expérience, cela n’a pas semblé complètement fiable.
Plus précisément, parfois, la navigation depuis la mise à jour terminée de Docker_manager vers la page Versions affichera la mise à jour de Discourse disponible pour commencer, puis ce n’est qu’après avoir actualisé la page qu’elle sera bloquée. [Je noterai que la dernière fois que j’ai vu cela se produire, c’était il y a très longtemps, peut-être que cela a été corrigé.]
Le besoin d’une reconstruction est lié à l’« image de base Docker » de Discourse, qui est totalement découplée du numéro de version de Discourse. Nous en avons besoin lorsqu’il y a des changements critiques dans les dépendances au niveau du système d’exploitation à l’intérieur de l’image docker.
Il serait donc délicat de l’inclure dans les notes de version de base de Discourse. Mais je comprends votre frustration de ne pas pouvoir mettre à jour depuis l’interface utilisateur. Peut-être pouvons-nous apporter des améliorations à l’interface utilisateur à cet égard.
ayant un filtre de « canal de publication » sur la page d’accueil
Toutes les publications
Publications de support étendu (ESR)
lors de la visualisation du canal ESR, seules ces publications sont listées, et cliquer sur une publication renvoie à la différence entre elles
Ceci dit, nous avons encore d’autres choses plus importantes à régler en ce moment pour le travail de versionnement en général (par exemple, la compatibilité des composants de thème / plugins).
Oh, je pense que ne pas pouvoir toujours utiliser l’interface utilisateur pour la mise à jour est acceptable et que toute personne (particulier, entreprise, etc.) qui héberge Discourse doit (devrait) avoir quelqu’un de disponible avec au moins des compétences de base en administration de serveur pour pouvoir effectuer des tâches telles que maintenir le système hôte à jour et reconstruire Discourse.
Les choses les plus importantes à mon avis sont :
Il ne devrait pas être possible de mettre à jour depuis l’interface utilisateur si un changement dépend d’une reconstruction avec une image Docker plus récente (au point de casser sans elle)
Il devrait être visible lorsqu’une reconstruction est nécessaire
Tant que l’interface utilisateur se met toujours à jour correctement après la mise à jour de Docker_manager, c’est-à-dire qu’elle ne peut pas se retrouver dans un état où elle sait que Docker_manager est à jour mais ne sait pas qu’une reconstruction est nécessaire, je pense que ces deux points sont déjà vrais.
