J’ai installé Discourse en auto-hébergement avec des plugins qui fonctionnent, mais Discourse se met à jour automatiquement sans mon accord. Récemment, le forum a cessé de fonctionner parce qu’un plugin n’était plus compatible.
Comme mon utilisation est déjà définie et que je n’ai pas besoin des nouvelles fonctionnalités de Discourse, comment désactiver les mises à jour pour éviter que les plugins ne cassent ?
Discourse ne se met pas à jour automatiquement. Nous n’avons même pas de fonctionnalité de mise à jour automatique.
Quelqu’un met-il à jour votre forum ? Ou avez-vous ajouté un travail d’arrière-plan manuel pour le faire sur le serveur hôte ?
C’est époustouflant, car je n’ai aucun plugin effectuant des mises à jour automatiques, et je ne vois rien dans le fichier app.yml, mais vous avez déjà mentionné que Discourse ne possède pas cette fonctionnalité.
Existe-t-il une méthode pour récupérer le moment exact (date et heure) de la dernière mise à jour de Discourse ?
D’accord, je vois. Il est indiqué que la dernière mise à jour date de 3 heures, et il y a 3 heures, j’ai exécuté :
./launcher rebuild app
Cette commande met-elle Discourse à jour ? Alors, comment installer des plugins sans mettre à jour Discourse ?
Oui, c’est la méthode principale pour mettre Discourse à jour.
Soit vous installez des plugins, soit vous vous trouvez dans le cas
Bien qu’il soit techniquement possible d’épingler Discourse à une version spécifique lors de l’installation de plugins, cela nécessite une analyse très minutieuse de la compatibilité des versions, de nombreux plugins supposant en effet une version récente de Discourse.
il est techniquement possible d’épingler Discourse à une version spécifique lors de l’installation des plugins
Comment faire cela ?
cela nécessite une analyse très minutieuse de la compatibilité des versions, de nombreux plugins supposant une version à jour de Discourse
Les plugins sont les miens, je ne veux pas qu’ils cessent de fonctionner, j’ai déjà eu une mauvaise expérience lorsque Discourse a modifié l’architecture ou autre. Je souhaite que le forum suive la philosophie de Golang.
Avez-vous envisagé de passer à la version ESR plutôt que de figer une version spécifique ? Vous bénéficieriez ainsi des correctifs de sécurité, tout en n’ayant à gérer les autres modifications que tous les six mois.
C’est un début, mais j’attendrai toujours quelqu’un qui puisse expliquer comment rester sur une version spécifique.
Je ne suis pas sûr de ce que vous attendez exactement. Le sujet que j’ai lié explique déjà comment configurer la version que vous souhaitez installer.
Vous avez dit que vous ne vouliez pas la version ESR, mais une version spécifique. Mais le même processus s’applique que vous utilisiez une branche, un tag ou un hachage de commit spécifique — vous remplacez simplement la valeur de version en conséquence. Vous pouvez également trouver des exemples à ce sujet dans le forum [1] [2]
Je recommande toujours d’éviter les commits épinglés en production, car vous ne recevrez pas de mises à jour de sécurité ou de correctifs à moins de les suivre manuellement.Mais ce sont en fait des révisions, en l’occurrence la branche que je souhaite utiliser. Je dis qu’il faut corriger le problème à une version donnée, comme la 2026.6.0, et ne plus jamais mettre à jour à partir de cette version. Ce que vous proposez, c’est de changer constamment de version, simplement en utilisant une autre branche.
Cela ne change rien si vous choisissez un référent qui ne bouge pas :
Mais tous les avertissements ci-dessus s’appliquent – cela n’est généralement pas recommandé.
Adopter cette approche (ou suivre une branche de version spécifique) signifie assumer davantage de responsabilités quant au suivi des dates de fin de support et gérer ces risques en conséquence.
J’ai dit que vous pouviez y mettre n’importe quelle version. Avez-vous consulté les exemples que j’ai liés ?
Quand pensez-vous qu’un hachage de commit fixe comme celui-ci changera ?
