À savoir avant de passer de la v3.4.0 à la v2026.7.2

Je suis responsable d’une installation de Discourse basée sur Docker, exécutée sur Ubuntu, que j’ai héritée dans le cadre d’un projet open source. Pendant des années, je la mettais à jour via git pull && ./launcher rebuild app, puis via l’interface d’administration située à /admin/update. Cependant, j’ai cessé de mettre à jour si légèrement après une expérience douloureuse lors d’une mise à jour majeure due à docker_manager en janvier 2024 (voir les commentaires sur le commit ici, et le commit annulé ici).

Cela fait maintenant 2,5 ans et j’ai besoin de reprendre le rythme des mises à jour, mais je suis encore un peu nerveux à cause de la dernière mise à jour qui a cassé. Ce que j’aimerais comprendre, c’est ce que je devrais savoir avant de tenter de passer de la v3.4.0 à la v2026.7.2. Notre site n’utilise aucun plugin supplémentaire, et la seule configuration particulière dont je sois conscient est que nous utilisons une URL Discourse Connect pour avoir la SSO avec notre site communautaire principal.

Est-ce aussi simple que ceci ?

cd /var/discourse
git pull
./launcher rebuild app

Et ensuite de mettre à jour via l’interface d’administration ? Y a-t-il des étapes intermédiaires dont je dois tenir compte en passant de la v3.4.0 à la v2026.7.2 ?

Merci,

Cory

Ou bien… (si vous êtes nerveux) … prenez une sauvegarde (dans tous les cas) et configurez un tout nouveau serveur, restaurez la sauvegarde, puis redirigez le domaine vers le nouveau serveur une fois terminé.

Le gros point auquel vous serez confronté est la mise à niveau majeure de Postgres (vers 18). Si vous construisez un nouveau serveur, vous n’aurez pas à gérer ce processus de mise à niveau.

Il existe également un petit risque que les plugins ou les composants de thème sur lesquels vous comptez n’aient pas été maintenus, en particulier s’ils sont écrits par des tiers moins actifs.

C’est précisément la nervosité qui pousse les administrateurs système Discourse expérimentés à utiliser une configuration à deux conteneurs, afin de pouvoir tester les mises à jour avant de les valider (bien que cela ne soit pas aussi utile lors d’une grosse mise à niveau de Postgres, mais celles-ci sont rares).