J’ai un système de longue durée, sans aucun problème auparavant. Je fais toujours une mise à jour en effectuant une reconstruction complète, jamais en utilisant la mise à jour intégrée.
Récemment, j’ai effectué une mise à jour via apt-get, une mise à jour de Docker vers la version 19.03.5, puis j’ai tenté une reconstruction, mais cela ne fonctionne plus. Le système est Ubuntu 16.04.6.
@j.jaffeuxDiscourse.redis doit-il être rétroporté vers stable et beta ? Je suppose que ce serait plus simple que d’ajouter du code pour la compatibilité ascendante dans plusieurs plugins.
Je suis presque certain que les dernières modifications cassent docker_manager, car il est mis à jour avant Discourse et ne trouve donc pas Discourse.redis.
Je sais que votre capacité à prédire l’avenir de manière fiable est quelque peu limitée, mais pensez-vous qu’une nouvelle version bêta soit prévue prochainement ?
Résumé court : tests-passed a fonctionné, j’ai eu 1 jour d’indisponibilité.
Version plus détaillée : Je pense qu’il s’agit de l’un des logiciels open source de la plus haute qualité écrits sur internet aujourd’hui, avec un modèle économique solide et une excellente équipe. Comment se fait-il que le mécanisme de mise à niveau soit simplement si défaillant ?
La fonctionnalité de mise à niveau dans l’application m’a causé tant d’indisponibilités que j’ai décidé de ne plus l’utiliser du tout, et de toujours procéder à une reconstruction.
Mais comme vous pouvez le voir dans ce fil de discussion, sur les 2 dernières tentatives, la reconstruction a également donné une application très cassée, quelque chose que je ne pouvais absolument pas réparer moi-même, si ce n’est en passant par « tests-passed » sur la base des recommandations ici.
Pourquoi le mécanisme de mise à niveau est-il si défaillant dans un logiciel aussi bien conçu ? Pourquoi est-ce que mes sites WordPress de plus de 5 ans fonctionnent sans aucun problème avec leur mécanisme de mise à niveau intégré ?
Quel est l’intérêt d’avoir des versions dans Discourse s’il n’y a littéralement aucun moyen de les utiliser ? Une reconstruction provient toujours d’une branche git, et les versions n’ont rien à voir avec git.
Pour moi, une version serait soit un tag git, soit un fichier zip. Pourquoi ne puis-je pas simplement utiliser la reconstruction avec la version 2.3.x, comme je pourrais le faire avec n’importe quel gestionnaire de paquets moderne aujourd’hui ?
Il s’avère que tests-passed est la version déployée par discourse.org sur leurs serveurs. Elle est mieux testée et plus fiable que stable. Si vous restez sur tests-passed, vous aurez moins de problèmes. Si vous souhaitez utiliser stable, sachez que cela demandera plus de travail que d’utiliser tests-passed, par exemple en exécutant un serveur de préproduction pour tester les mises à jour avant de les déployer en production.
Je veux simplement quelque chose de stable et fiable, et basé sur
tests-passed est ce que discourse.org déploie sur ses serveurs ; c’est mieux testé et plus fiable que stable.
Je vais m’en tenir à cela. Deux choses restent très étranges :
Pourquoi cela s’appelle-t-il test-passed et non stable, s’il est effectivement stable ? « stable » pourrait être renommé « legacy » ou quelque chose de similaire.
Le système de publication n’a toujours pas de sens. Si nous construisons à partir d’une branche Git, quel est l’intérêt de faire des versions à tout prix ? J’aimerais pouvoir rester sur la 2.3.x jusqu’à ce que la 2.4.x soit mature, par exemple, et je pense que ce n’est pas du tout possible avec le modèle de Discourse.
Avec tout le respect dû, je ne suis pas d’accord avec cela. Stable est très fiable et, eh bien, stable. Rubygems a mis à jour une dépendance, ce qui a cassé à la fois tests-passed et stable, et la résolution de ce problème n’était qu’une question de rétroportage d’un correctif.
D’ailleurs, cela aurait pu être évité en épinglant Rubygems à une version spécifique dans la commande gem update. gem update --system 3.0.6 aurait été sûr.
Le fait que stable ait été cassé plus longtemps que tests-passed est simplement une coïncidence et, à ma connaissance, une première.
Nous faisons cela (rester sur stable par défaut) depuis plus de six ans avec des centaines d’instances Discourse sans problèmes majeurs.
Justement dans ce fil, il y a plusieurs cas où la version stable a été reconstruite dans un état cassé ; ce n’est absolument pas la première fois. Si les instances commerciales de discourse.org ont passé les tests, je m’en tiendrai à celles-ci.
Nous faisons cela (s’en tenir à la version stable par défaut) depuis plus de six ans avec des centaines d’instances Discourse, sans problèmes majeurs.
S’en tenir à la version stable et s’en tenir à la 2.3.x sont deux choses très différentes. Par exemple, la version stable ne vous permet pas de rester sur la 2.3.x tant que la 2.4.x n’est pas suffisamment mature. Par exemple, dans un environnement de production, je préfère ne faire la mise à niveau qu’une fois que la x.x.3 ou la x.x.4 est sortie. À mon avis, ce n’est pas possible aujourd’hui.
Je sais que c’est vrai, mais vous n’êtes pas l’administrateur Discourse moyen. Vous m’avez sauvé la mise à plusieurs reprises, et par principe, je relis tout ce que vous dites deux fois pour m’assurer de bien retenir. Cependant, je pense toujours que, pour la plupart des gens normaux, il est plus prudent de s’en tenir à la version « tests-passed ».
Vous pouvez utiliser un identifiant de commit Git plutôt qu’une balise.
Mais même si je le fais, cela ne m’aidera pas dans une situation où la version stable est cassée, n’est-ce pas ? Dans les deux cas, le problème était un backport manquant, et celui-ci manquerait tout autant dans n’importe quel ID de commit git, je pense.
Par conséquent, il n’existe pas de « version » Discourse au sens où vous téléchargez un fichier zip à la manière de WordPress ou utilisez un gestionnaire de paquets comme yarn/pip/gem, simplement parce que Discourse n’est pas « publié », mais est « reconstruit », en utilisant toujours les versions en direct des packages externes.
Vous m’avez sauvé la mise à plusieurs reprises, et par principe, je relis tout ce que vous dites deux fois pour m’assurer de bien retenir. Cependant, je pense toujours que, pour la plupart des gens normaux, il est plus prudent de s’en tenir à la version « tests-passed ».