J’ai remarqué que de temps en temps, mon site Discourse m’envoie un e-mail indiquant qu’une nouvelle version est disponible pour installation, mais à chaque fois, la version est « x.y.z.beta quelque chose ». Je voudrais donc savoir : Discourse est-il toujours dans une version « bêta » ? Est-il recommandé de l’installer dans un environnement de production (c’est-à-dire pour servir des centaines, voire des milliers de personnes) ? Ou cela ne concerne-t-il que les versions gratuites et non les versions « cloud » ?
6 « J'aime »
Voici une bonne explication des branches que nous utilisons ici :
Ainsi, Discourse se trouve dans un état de bêta perpétuelle, ce qui signifie que nous travaillons constamment sur de nouvelles fonctionnalités et des améliorations. Dans notre cas, « bêta » ne signifie pas instable ; nous hébergeons des sites avec des millions de vues mensuelles sur nos versions tests-passed et beta.
24 « J'aime »
Pour compléter ce que @awesomerobot a posté :
Notre nomenclature diffère légèrement de celle d’autres entreprises de logiciels, mais lorsqu’on publie une bêta, cela signifie que nous lançons une nouvelle version incrémentale. Nous nous disons : « C’est assez de changements pour le moment. Informons les sites des nouvelles mises à jour. »
Ainsi, pour nous, une bêta correspond à une augmentation mineure de version, tandis qu’une version correspond à une augmentation majeure. Ce sont des jalons que nous nous fixons pour célébrer le travail accompli. Nous avons tendance à publier deux versions majeures par an, mais cela dépend entièrement du développement des fonctionnalités et d’autres facteurs. Nous ne sommes pas vraiment partisans de faux délais.
Concernant les branches
Stable/bêta ne sont pas nécessairement plus « stables » que tests-passed. Il s’agit plutôt du fait que les bogues sont connus. Avec tests-passed, de nouveaux bogues peuvent être introduits puis corrigés quelques commits plus tard.
Tests-passed ne diffère pas beaucoup des autres releases logicielles courantes, qui publient généralement de petits changements toutes les deux semaines. Nous intégrons de nouveaux changements presque quotidiennement, et ils sont disponibles via tests-passed.
17 « J'aime »
Je suis sur ce fil de discussion pour la même raison.
Pourquoi les instructions d’installation ne nous disent-elles pas d’installer la branche stable ?
Comment puis-je passer à la branche stable ou est-il trop tard puisque je suis sur une « version supérieure » ?
Les instructions peuvent-elles être mises à jour ?
S’il est trop tard, comment rester sur la branche stable une fois qu’elle sera mise à jour ?
Dois-je continuer à mettre à jour progressivement jusqu’à y arriver ?
2 « J'aime »
Vous ne pouvez pas revenir à la version stable tant qu’elle n’a pas rattrapé son retard. Discourse ne prend pas en charge les rétrogradations.
Une meilleure question est : pourquoi le voudriez-vous ?
La version stable n’est pas aussi largement utilisée, l’accent du développement est mis sur les tests réussis.
En supposant que vous ne mettez pas à niveau aveuglément un site de production et que vous testez chaque mise à niveau avant le déploiement, la version la plus riche en fonctionnalités et la mieux prise en charge sera la version par défaut.
4 « J'aime »
Désolé, cela doit être un problème de barrière linguistique, mais l’objectif signifie-t-il :
- le développement de Discourse lui-même et la manière dont les branches sont construites
- tout le monde fait principalement du développement de Discourse
Le premier signifie que les sites de production qui se concentrent sur un forum fonctionnel et stable devraient utiliser test-passed.
Le second signifie qu’un site de production, qui produit un forum, pas du code, devrait utiliser stable.
Oui. J’ai désespérément besoin de leçons d’anglais car ces nuances ne me sont pas totalement claires.
Mais si la première supposition est correcte, pourquoi y a-t-il une branche stable si elle n’est pas censée être utilisée ?
2 « J'aime »
Nous exécutons tests-passed en production sur notre hébergement. Il est 100% destiné aux sites de production.
Stable signifie que tous les bugs logiciels sont connus. Vous n’obtiendrez rien de nouveau (y compris de nouveaux bugs, mais aussi des corrections de bugs) avant la sortie de la prochaine version stable. C’est simplement une préférence du site : vous voulez les fonctionnalités au fur et à mesure ? Utilisez tests-passed. Vous voulez une version absolument stable qui ne changera pas, sauf lors des mises à jour majeures ? Utilisez stable.
10 « J'aime »
J’ajouterais : « voulez-vous attendre 6 à 8 mois pour qu’un bug qui n’est pas considéré comme un risque de sécurité soit corrigé ? » Utilisez stable.
11 « J'aime »
Ce n’est pas entièrement vrai. De nombreuses corrections de bogues sont rétroportées vers la version stable.
4 « J'aime »
C’est tout à fait vrai, j’en suis sûr.
Mais l’hyperbole, c’est la meilleure chose qui soit !
5 « J'aime »
C’est vrai, les bogues bloquants. Les bogues mineurs ne le sont pas.
2 « J'aime »
Ce serait bien s’il y avait un choix dans les instructions générales, un peu comme les choix de téléchargement de LibreOffice ou Debian.
J’héberge le site sur DO mais mon co-propriétaire venait à l’origine de discoursehosting.net en tant que sous-domaine, et il voit toute cette maintenance et dit « Pourquoi n’utilisons-nous pas simplement l’hébergement Discourse ? »
Je lui ai dit que nous avions notre propre nom, notre propre serveur, des plugins de niveau supérieur (comme les likes d’emoji et la connexion Google) et d’autres choses. Je lui ai dit qu’il utilisait probablement une ancienne version de Discourse et qu’il ne l’avait jamais mise à jour non plus.
Moi aussi, je préférerais simplement utiliser la version stable et l’oublier pendant 6 mois. Je suis un utilisateur quotidien d’Ubuntu, mais je suis un peu nerveux lorsque je tape ces quelques commandes de compilation. De plus, le serveur tombe en panne pendant 5 minutes lorsque je reconstruis.
D’un autre côté, je vais demander l’intégration d’une fonction de sauvegarde et je sauterais sur la bêta pour cela 
Juste pour éviter toute spéculation : chez Communiteq (anciennement discoursehosting.net), vous obtenez votre propre nom d’hôte, des plugins de votre choix à partir du plan Professionnel et supérieur, et nous sauvegardons et mettons à jour votre forum pour vous. Donc oui, la plupart de vos problèmes seront effectivement résolus en utilisant l’hébergement géré.
4 « J'aime »
Le problème initial était de demander une option de build stable dans les instructions d’installation GitHub. Je vois que vous fournissez des versions stables à vos clients. Peut-être pourriez-vous expliquer comment cloner et installer une version stable ? C’était aussi ma question initiale.
En tant que groupe restreint et semi-privé, il n’y a aucune justification pour autre chose que le serveur DO à 5 . Cependant, vous avez un excellent service pour 40 par mois pour le plan professionnel ou le plan de base. Je vous souhaite bonne chance. C’est une bonne affaire par rapport aux plans officiels de Discourse. Toutes les options sont excellentes pour ceux qui peuvent se le permettre. C’est la beauté du FOSS.
1 « J'aime »
J’ai cru comprendre que la décision d’installer par défaut sur les tests réussis était tout à fait intentionnelle.
Il est beaucoup plus facile de prendre en charge de nouvelles installations à un seul niveau logiciel. Comme le support fourni ici est basé sur la communauté et, pour la plupart, 100 % gratuit, il n’y a aucune bonne raison de le compliquer.
5 « J'aime »
Les instructions d’installation standard sont simplifiées pour une raison.
Exécuter stable est considéré comme une configuration avancée, vous devez donc modifier app.yml à la main. Vous pouvez rechercher « version » et voir ce qu’il faut faire documenté là-bas.
Modifier discourse-setup pour inclure cela comme une option serait déroutant pour la plupart des gens, donc je ne pense pas que cela y sera ajouté.
2 « J'aime »
Peut-être qu’une métaphore utile est que la branche « stable » est comme Microsoft Office basé sur disque, tandis que la branche « tests-passed » est comme Office 365 basé sur le cloud. Les deux sont des options viables, et les deux reçoivent des mises à jour éventuellement, mais pour un produit qui est fondamentalement déjà en ligne et qui a une petite équipe de support, il est plus productif de pouvoir demander aux gens de mettre à jour leurs installations vers le code actuel, afin que les bogues puissent être testés et corrigés rapidement. En tant qu’administrateur de forum, il est formidable de pouvoir signaler un bogue et de passer à une version qui le corrige en quelques jours, parfois même le lendemain. Je n’ai utilisé aucune autre application web aussi réactive. (Ce n’est pas que tous les bogues soient corrigés instantanément, mais beaucoup le sont.)
11 « J'aime »
@pfaffman, j’ai suivi le lien et celui auquel il menait, mais je n’ai rien vu concernant la configuration de stable. Qu’est-ce qui me manque ? Voulez-vous dire « rechercher dans le fichier app.yml le terme « version » » ?
mais je ne pense pas que vous puissiez passer de test-passed à stable (car vous reviendriez en arrière dans le commit et auriez probablement besoin d’inverser certaines migrations dans la base de données, à moins que votre version test-passed ne soit assez ancienne pour être dépassée par la plus récente version stable, je suppose 
)
4 « J'aime »
Merci pour votre réponse rapide !
Je m’attendais à ce que la mise à jour soit simplement suspendue jusqu’au prochain cycle de publication stable.
Avez-vous des éclaircissements à ce sujet ? Pourquoi quelque chose changerait-il immédiatement en basculant l’interrupteur #version ?
1 « J'aime »