Changer de canal de version Discourse

[Discourse]

Ce guide explique comment configurer le canal de mise à jour de votre instance Discourse.

Niveau d’utilisateur requis : Administrateur système

L’accès à la console est requis.

La gestion du canal de votre instance Discourse détermine la fréquence et le type de mises à jour que vous recevez. Ce guide explique les canaux disponibles et fournit une approche étape par étape pour modifier la branche dans votre configuration.

Résumé

Discourse propose plusieurs canaux pour suivre les mises à jour logicielles : latest, release et esr. Cette documentation explique l’objectif de chacun, leurs caractéristiques principales et comment les configurer dans votre instance Discourse. Pour une illustration des canaux, consultez releases.discourse.org.

Canaux pris en charge

latest

Défaut recommandé
Ce canal fournit les dernières corrections de bugs et les mises à jour de compatibilité pour les plugins. Chaque commit passé de la branche main est testé par le serveur de construction et ajouté à la branche latest après vérification réussie.

• Convient aux sites qui souhaitent rester à jour.
• Les sites peuvent mettre à jour manuellement à tout moment.

release

Pour les sites qui préfèrent les versions mensuelles

Le canal release suit la version mensuelle la plus récente de Discourse. Chaque mois, une branche de version (par exemple release/2026.2) est créée à partir de latest, fournissant un instantané stable.

• Publiée environ une fois par mois.
• Chaque version reçoit des corrections critiques pendant deux cycles de version complets.

esr

Version à support étendu (Extended Support Release)

Le tag esr suit la dernière version à support étendu, destinée aux sites qui privilégient la stabilité et la sécurité à long terme par rapport aux mises à jour fréquentes.

• Déclarée environ tous les 6 mois à partir des versions mensuelles.
• Reçoit des correctifs de sécurité et des rétroportages critiques pendant une période prolongée.
• Peut avoir une compatibilité limitée avec les plugins communautaires et les composants de thème.

Remarque : Le fait de ne pas recevoir de mises à jour de maintenance régulières peut laisser certaines fonctionnalités obsolètes ou visuellement incohérentes.

Aliases dépréciés

Pour la compatibilité ascendante, les anciens noms de branche/tag suivants fonctionnent toujours mais sont considérés comme dépréciés :

• tests-passed → latest
• beta → release
• stable → esr

Autres branches ou références

Le suivi d’autres branches (par exemple, des branches spécifiques release/AAAA.M ou des SHA de commit) est possible mais nécessite une expertise. Ces branches ne reçoivent des corrections critiques que pour une période limitée.

Instructions pour configurer votre canal

Suivez ces étapes pour configurer la branche souhaitée dans votre instance Discourse :

1. Accéder au fichier de configuration
   Ouvrez le fichier de configuration app.yml en exécutant les commandes suivantes dans votre console :

cd /var/discourse
nano containers/app.yml

L’éditeur nano ouvrira le fichier de configuration.
2. Modifier la branche de suivi
Localisez le paramètre de version en recherchant le mot “version” dans le fichier :

params:  
## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : latest)  
#version: latest

• Décommentez la ligne de version.
• Remplacez latest par le nom de la branche ou du tag de votre choix (par exemple, esr). Exemple :

params:  
## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : latest)  
version: esr  

3. Sauvegarder et quitter

• Appuyez sur Ctrl+O pour sauvegarder vos modifications.
• Appuyez sur Entrée pour confirmer.
• Utilisez Ctrl+X pour quitter l’éditeur.

4. Reconstruire le conteneur
   Une fois les modifications apportées et sauvegardées, reconstruisez le conteneur pour appliquer la nouvelle configuration :

./launcher rebuild app

La reconstruction entraînera une interruption temporaire de service

[david (David Taylor) A scindé ce sujet ()]

4 messages ont été fusionnés dans un sujet existant : Aide pour le déploiement de versions antérieures de Discourse

[ghorbani (Aref)]

@Discourse

cd /var/discourse
git pull
nano containers/app.yml

L’étape git pull est-elle nécessaire, ou est-elle redondante et subsiste-t-elle de la documentation ancienne, comme c’est le cas pour la mise à jour de Discourse (Mettre à jour manuellement Discourse et l’image Docker vers la dernière version) ?

[merefield (Robert)]

D’après mon expérience, git pull est occasionnellement utile — par exemple, c’était indispensable lorsque nous sommes passés de yarn à pnpm …

En règle générale, vous n’avez pas besoin de vous en soucier pour une reconstruction standard.

[ghorbani (Aref)]

Bon à savoir ! Merci pour les informations.

[merefield (Robert)]

Ce que je fais habituellement c’est essayer de reconstruire, et si cela échoue pour une raison pas si évidente que ça, je commence par faire un git pull — ça ne prend qu’un instant.

[david (David Taylor)]

En théorie, cela ne devrait jamais être nécessaire. Le lanceur détectera automatiquement une copie obsolète et effectuera lui-même le git pull :

launcher

[ghorbani (Aref)]

Merci pour ces précisions. En effet, cela a du sens. Je vais essayer sans git pul et je vous tiendrai au courant du résultat.

[Ed_S]

C’est bizarre. Le code en question date de 2015, mon forum date de 2018, et pourtant je suis presque certain qu’il y a eu plusieurs cas discutés ici où git pull était nécessaire.

Pour ma part, je ferai toujours un git pull, si je m’en souviens — ça ne me coûte rien.

[david (David Taylor)]

Cela est souvent mentionné, je pense à cause de ces documents très historiques. Je ne crois pas avoir jamais vu de preuve que cela ait réellement aidé.

Mais oui, il n’y a aucun inconvénient à l’exécuter manuellement aussi

[Ed_S]

@Discourse

## Which Git revision should this container use? (default: latest)  
#version: latest

Étant donné que le fichier yml utilise version et non supported tracking branch, serait-il judicieux d’ajouter (version) au titre du sujet ?

[ghorbani (Aref)]

La date m’a aussi un peu choqué au début. Mais en vérifiant l’historique des versions, la dernière mise à jour est du 18 mai.

[david (David Taylor)]

J’ai tenté de mettre à jour le message initial pour utiliser notre terminologie moderne de « chaîne » et supprimer certaines références inutiles à git pull.

[merefield (Robert)]

Il doit y avoir au moins un cas limite, car cela m’a définitivement « aidé à franchir l’obstacle » dans des situations très rares.

Cela pourrait-il arriver lorsque le script principal change dans des circonstances limitées ?