I noticed that every now and then my Discourse site send me an email telling that a new version is available to install, but every time the version is “x.y.z.beta something”, so I’d like to know: is Discourse always some “beta” version? Is it good to install in a production environment (i.e. to serve hundreds, maybe thowsands people)? Or does this concerns only free and not “cloud” versions?
6 « J'aime »
There’s a good explanation of the branches we use here:
So Discourse is in a perpetual beta state, meaning that we’re always working on new features and refinement. In our case beta does not mean unstable; we host sites with millions of monthly pageviews on our tests-passed and beta versions.
24 « J'aime »
To add to what @awesomerobot posted:
Our nomenclature is a bit different than other software companies, but what it means when we release a beta is we’re releasing a new incremental version. We’ve said, “That’s enough changes for now. Let’s notify sites about new updates.”
So for us, a beta is a minor version bump, and a version is a major version bump. They’re checkpoints we give ourselves to celebrate the work we’ve done. We tend to release two major versions a year, but it all depends on feature development and the like. We’re not really into fake deadlines.
Regarding the branches
Stable/beta are not necessarily any more “stable” than tests-passed. It’s more the idea that the bugs are known. With tests-passed there may be new bugs introduced then fixed a few commits later.
Tests-passed is not much different than most other software releases out there, which usually release small changes every two weeks. We commit new changes almost daily instead, and they’re available 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 »