Pour plus d’informations sur toutes les modifications publiées dans la version 2026.7, consultez :
Des versions correctives pour les autres versions prises en charge ont également été publiées :
4 « J'aime »
Cela devient-il la version « esr » actuelle, ou ai-je mal compris quelque chose ?
1 « J'aime »
En effet, je n’arrive pas à comprendre ce qui s’est passé. Pour cette mise à jour (très urgente en raison de Cache poisoning/XSS via color scheme cookies · Advisory · discourse/discourse · GitHub), une reconstruction était nécessaire, mais comme il y avait un journal des modifications v2026.1.5 → v2026.1.6, j’ai supposé qu’il s’agirait d’une mise à jour mineure de version. Mais non, je suis maintenant sur la v2026.7.0. Pour autant que je sache, mon forum est configuré pour être sur esr :
params:
db_default_text_search_config: "pg_catalog.english"
## Fixez db_shared_buffers à un maximum de 25 % de la mémoire totale.
## sera défini automatiquement par bootstrap en fonction de la RAM détectée, ou vous pouvez le remplacer
db_shared_buffers: "2048MB"
## peut améliorer les performances de tri, mais augmente l'utilisation de la mémoire par connexion
db_work_mem: "40MB"
## Réduire la taille maximale des téléchargements
upload_size: 1m
## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : tests-passed)
version: esr
J’ai également été assez surpris de voir toute une série de requêtes post-mise à jour comme celles-ci :
== 20260421061908 AddCoveringIndexOnChatMessagesThreadId: migration en cours ===========
-- remove_index(:chat_messages, {name: "idx_chat_messages_thread_id_id_user_id_not_deleted", algorithm: :concurrently, if_exists: true})2026-07-28 16:02:43.673 UTC [544] discourse@discourse LOG: durée : 16903.716 ms instruction : CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_localization" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:02:59.214 UTC [544] discourse@discourse LOG: durée : 15529.318 ms instruction : CREATE INDEX CONCURRENTLY "index_posts_on_updated_at_for_locale_detection" ON "posts" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.031 UTC [544] discourse@discourse LOG: durée : 798.943 ms instruction : CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_locale_detection" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NULL
2026-07-28 16:03:00.186 UTC [544] discourse@discourse LOG: durée : 143.500 ms instruction : CREATE INDEX CONCURRENTLY "index_topics_on_updated_at_for_localization" ON "topics" ("updated_at" DESC) WHERE deleted_at IS NULL AND user_id > 0 AND locale IS NOT NULL
2026-07-28 16:03:01.251 UTC [544] discourse@discourse LOG: durée : 1051.872 ms instruction : UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 1
AND id < 10001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2026-07-28 16:03:01.910 UTC [544] discourse@discourse LOG: durée : 658.965 ms instruction : UPDATE posts
SET raw = regexp_replace(
raw,
'\\+([_*~|`])(?=[^\]\[]*\]\(upload://)',
'\1',
'g'
)
WHERE id >= 10001
AND id < 20001
AND raw ~ '\\+[_*~|`][^\]\[]*\]\(upload://'
2 « J'aime »
Oui, c’est le cas !
Cette version est une nouvelle version ESR, donc vous y avez basculé lors de votre mise à jour.
3 « J'aime »
Pourrait-on rendre cela moins confus à l’avenir ? Peut-être que c’est juste moi, mais si une mise à jour est appliquée à la branche ESR sur laquelle je me trouve actuellement, je suppose que c’est parce que la version majeure actuelle de cette branche est toujours prise en charge.
2 « J'aime »
La version 2026.1 est toujours prise en charge, et vous pouvez figer votre installation sur cette version en définissant version: release/2026.1 dans votre fichier app.yml. Dans ce cas, une reconstruction aurait intégré la mise à jour de sécurité sur la branche 2026.1.
Je suppose que vous utilisiez version: esr ? Dans ce cas, vous suivez la version « esr la plus récente », qui est maintenant la 2026.7.
Vous trouverez des informations sur les périodes de prise en charge, ainsi que les chevauchements entre les prises en charge ESR, sur https://releases.discourse.org/
Malheureusement, il n’est pas possible de rétrograder Discourse. Mais si vous souhaitez éviter cela à l’avenir, vous pouvez figer la version sur release/2026.7 (et veiller à mettre à jour ce paramètre manuellement avant que la version 2026.7 ne sorte de sa période de prise en charge).
1 « J'aime »
Merci. Je suppose que je cherche la méthode la plus infaillible/automatisée pour rester définitivement sur la version la plus ancienne encore prise en charge, c’est-à-dire le chemin de développement le plus lent.
3 « J'aime »
Idem, et je pense que l’esr (presque) fait cela. Toutes les quelques mois, il y a un nouvel esr et vous passez à celui-ci, ce qui vient d’arriver. Mais en réalité, l’ancien esr a encore deux mois de durée de vie maintenue, donc vous vous attendiez à rester sur cet esr précédent. (Je pense que c’est une chose raisonnable de vouloir faire. Avons-nous besoin d’un label esr-maintenu ??)
4 « J'aime »
Je pense que c’est une chose raisonnable à envisager, mais réfléchissez aussi à ceci… que serait-il différent dans 2 mois, une fois que v2026.1 ne sera plus maintenu ?
Sans modifications supplémentaires, vous seriez toujours mis à jour à ce moment-là « sans avertissement ».
Est-ce acceptable ?
1 « J'aime »
Oui, je pense qu’il est toujours pertinent de vouloir rester plus longtemps sur l’ancienne version ESR. Cela signifie que la nouvelle version ESR a été testée et qu’elle a peut-être intégré certaines corrections.
J’ai adopté la nouvelle version ESR dans l’heure qui a suivi et je le regrette un peu : dans le monde actuel, le meilleur conseil serait de figer la version précédente et de n’appliquer que les correctifs de sécurité. Cela dissocie le correctif de sécurité urgent de la courbe d’apprentissage administrative et des nouveaux bogues qui seront bientôt corrigés. Voir le très utile
Passer de l’ESR 2026.1 à l’ESR 2026.7 - Ce que j’ai découvert
(Pourquoi s’attendre à de nouveaux bogues dans une version ESR fraîchement sortie ? Parce que, autant que je sache, la nouvelle version ESR a été en développement continu jusqu’au moment de sa sortie. Il n’y a pas de phase de stabilisation.)
2 « J'aime »
C’est la grande question.
Donc, si j’étais sur esr-maintained, alors après deux mois, esr et esr-maintained seraient la même branche, n’est-ce pas ? Donc, après 2 mois, je serais toujours surpris par le grand changement.
Tant que esr et esr-maintained ne sont pas la même branche, Discourse pourrait émettre/afficher un avertissement indiquant que vous êtes entré dans la « période de grâce ESR ». Cet avertissement ne pourrait être affiché que sur le forum pour les administrateurs, et non lors de la reconstruction du conteneur.
Avoir un préavis concernant le basculement ESR serait agréable afin de pouvoir planifier et tester la mise à niveau pendant cette période de grâce prise en charge.
4 « J'aime »
Dans un monde idéal, cela vous donne deux mois pour mettre à jour votre serveur de préproduction vers le nouvel ESR, tandis qu’en production, vous pouvez continuer à utiliser l’ancien ESR avec les correctifs de sécurité pour couvrir cette période.
Il est effectivement logique d’avoir une sorte de suivi simple des étiquettes pour suivre l’ancien ESR corrigé, afin de récupérer automatiquement les mises à jour de maintenance de l’ancien ESR.
Peut-être existe-t-il déjà un moyen d’y parvenir ?
2 « J'aime »
Je ne pense pas que la version ESR recevra autant de correctifs de bugs. Tout comme pour la version 2026.1, elle ne recevra plus que des correctifs de sécurité à partir de maintenant.
Ainsi, même si certains de ces bugs seront connus dans un mois, cela ne signifie pas pour autant que vous n’aurez pas à vous en occuper.
3 « J'aime »
Pour adopter un point de vue pessimiste, nous verrons bien ! J’imagine que s’il y avait un changement cassant stupide trouvé dans une ESR fraîchement créée, il serait corrigé. Peut-être que ce nouveau monde n’est pas encore en place assez longtemps pour voir cela se produire. En effet, je ne m’attendrais pas à ce que des corrections soient apportées pour de simples inconvénients.
1 « J'aime »