Il n’y a pas de définition formelle de « vérifié » dont j’aie connaissance.
Tous les logiciels sont potentiellement bogués.
tests-passed contient les commits les plus à jour. beta ne reçoit que les versions bêta. stable ne reçoit que les versions stables.
tests-passed est ce qui est exécuté sur pratiquement tous les sites hébergés sur discourse.org et sur la grande majorité des sites auto-hébergés.
@mcwumbly – avons-nous un document « quelle version dois-je exécuter ? » J’ai cherché un peu et je n’en ai pas trouvé. Tout ce dont je me souviens, c’est quelque chose comme ceci des annonces de stable.
J’ai séparé cela (je pense que c’est la première fois que je le fais !), car le pauvre âme ne peut toujours pas dire si c’est « dangereux » de mettre à niveau, et cette discussion sur la façon de résoudre le problème des personnes qui ne savent pas s’il faut mettre à niveau n’aide pas.
Peut-être que Is Discourse always in "beta"?, est ce que je cherchais (mais j’ai oublié que c’était là pour le chercher).
L’autre chose qu’il a demandée, qui est là où il a commencé, et que je pense être tout à fait raisonnable, est : « Si je suis sur la dernière version bêta, pourquoi ai-je besoin de mettre à niveau ? » Et ce qui précède répond assez directement à cela.
Je ne pense pas que nous devrions le faire. Nous voulons que les gens utilisent tests-passed. Les instructions d’installation officielles doivent mener à une installation par défaut avec autant de paramètres que possible correspondant à ce que nous voulons. Cela inclut la branche qui est suivie.
Il y aura toujours des gens qui décideront d’utiliser, par exemple, la dernière version stable. Ne pas avoir de guide sur la façon d’y parvenir à l’endroit le plus intuitif ne fera pas disparaître ces personnes ; cela leur rendra simplement les choses un peu moins pratiques - et signifie probablement parfois qu’ils viendront ici pour poser des questions, et que d’autres passeront du temps à y répondre (encore et encore).\n\nL’argument le plus fort, cependant, est probablement que le guide peut leur montrer comment le faire correctement, ce qui signifie qu’ils pourront revenir en arrière plus tard s’ils changent d’avis. S’ils ne savent pas, ils pourraient finir par casser leur installation, ce qui sera gênant pour eux et pour leur communauté.\n\nSi INSTALL-cloud.md a une section sur le changement de branche, cela peut clarifier quelle est la branche par défaut et pourquoi, en précisant que la branche par défaut est la plus utilisée et la plus facile à prendre en charge.
Je suis 100% d’accord pour qu’il y ait un guide sur Meta expliquant comment changer de branche. Je ne pense juste pas que cela appartienne au guide d’installation officiel, où 95% des gens ne s’en soucient pas ou n’ont pas besoin de s’en soucier.
Si Bob le Débutant essaie d’installer Discourse, il veut juste terminer l’installation le plus rapidement et le plus facilement possible, afin de pouvoir travailler sur son nouveau site. Les informations sur le changement de branche ne feront que le faire réfléchir davantage et causer de la confusion.
Ally l’Avancée, en revanche, peut être intéressée à comprendre comment fonctionnent les branches et laquelle est la meilleure pour son site. Mais elle fait probablement aussi plus de recherches avant d’installer Discourse, et ne se contente pas de parcourir le guide d’installation.
En effet, tel quel, nous recevons de temps en temps des sujets d’utilisateurs souhaitant revenir à la version bêta ou stable et qui échouent.
Le mettre dans la documentation d’installation standard ouvrirait vraiment les vannes, à la fois en raison de ce qui précède et des problèmes de compatibilité des plugins avec les anciennes versions.
Je suis d’accord. Tout bien considéré, j’ai l’impression que beta confond plus les gens qu’il ne remplit une utilité.
Je pense qu’il est utile de faire une distinction entre les choses que l’on utilise et qui ont un sens en interne, et les choses qui ont un sens pour des tiers. La branche beta en est un bon exemple. Bien qu’elle puisse avoir une certaine utilité interne, elle a peu d’utilité pour les tiers et les confond parfois.
Je serais intéressé d’entendre le contraire, mais en y réfléchissant maintenant, je ne me souviens pas d’un auto-hébergeur sérieux qui utilise réellement beta de manière significative. « Bob le basique » ne sait pas vraiment ce qu’est une branche et s’en fiche probablement (et c’est normal). « Ally l’avancée » utilisera tests-passed si elle est un particulier ou une PME, et pourra utiliser stable (ou épingler des commits) si elle est une entreprise de taille moyenne ou grande.
Ma suggestion serait de garder tout au niveau des branches exactement comme il est, mais de dire publiquement « Nous avons deux branches que vous pouvez utiliser : tests-passed (la valeur par défaut et la meilleure) et stable (si vous savez ce que vous faites et que vous avez un besoin particulier). »
De mon côté, le simple fait d’avoir le nom de la branche tests-passed visible à côté du nom de la version sur le tableau de bord serait une amélioration suffisante.
Je suis tout à fait d’accord. Quiconque souhaite utiliser une branche différente la trouvera presque toujours.
S’ils ne peuvent pas la trouver avec les ressources existantes (recherche, projet GitHub standard), sont-ils vraiment équipés des compétences nécessaires pour comprendre pleinement la différence entre les branches, et encore moins pour s’écarter de la sécurité de la branche par défaut ?
Bien sûr, c’est logique. Mais j’ai l’impression que nous ratons une occasion d’aider les gens à comprendre la distinction entre les différentes options ici. Je ne vois aucun inconvénient à dire aux auto-hébergeurs que la valeur par défaut est tests-passed, ce qui est idéal pour la plupart des sites et garantit que vous recevez les derniers correctifs de sécurité et mises à jour. Si vous êtes averse au risque, vous pouvez laisser tests-passed et ne mettre à jour que lorsque le logiciel vous y invite, ou une semaine environ après avoir reçu l’invitation. De cette façon, d’autres personnes découvrent d’abord les problèmes et ils sont corrigés avant que vous ne mettiez à jour.
Compte tenu de ce qui précède, existe-t-il des raisons légitimes pour les auto-hébergeurs de passer de tests-passed ? Je suppose que si votre site est fortement modifié et qu’il échouera si le cœur de Discourse ou les plugins officiels sont mis à jour, et que vous ne vous faites pas confiance ou ne faites pas confiance à vos administrateurs pour ne pas mettre à jour ? Ou si vous configurez un environnement de développement ou de staging ?
Un autre endroit pour expliquer cela pourrait être dans app.yml qui est actuellement assez cryptique car il ne fait référence qu’à tests-passed et ne mentionne pas les options ni quand vous pourriez passer à une autre.
## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : tests-passed)
#version: tests-passed
À mon avis, utiliser autre chose que tests-passed n’a de sens que si vous êtes sur un service d’hébergement géré ou : 1) si vous avez une équipe qui gère votre communauté (c’est-à-dire que vous êtes une entreprise moyenne à grande) ; et 2) vous avez une raison spécifique de ne pas utiliser tests-passed, par exemple vous avez plusieurs personnalisations qui pourraient échouer.
Je dirais que les deux conditions sont nécessaires, car à moins d’avoir une équipe qui gère votre communauté dans le scénario de personnalisations multiples et fragiles, votre problème n’est pas l’utilisation de votre branche mais la gestion globale de votre site (c’est-à-dire que ce n’est pas durable).
Même si les deux sont vraies, il y aurait d’autres choses à prendre en compte d’abord, comme votre politique de mise à jour.
Je pense que le problème est que si vous disiez quelque chose comme “Vous pouvez utiliser stable ou tests-passed”, certaines personnes mettraient stable parce que cela semble “sensé” alors qu’elles ne devraient probablement pas l’utiliser.
Où va la branche beta ?
Pour renforcer l’argument contre la branche beta, dans divers contextes écrits et oraux, les principales confusions qu’elle produit sont :
Les gens associent normalement le terme “beta” à quelque chose de plus à la pointe de la technologie que le “standard”. Ce n’est pas le cas ici.
Certaines entreprises envisagent de l’utiliser car elle semble un peu moins à la pointe que tests-passed et un peu plus à jour que stable, c’est-à-dire encore une fois, elle semble “sensée”. Mais dans la plupart des cas, ce n’est pas une bonne idée.
“beta” est un terme utilisé à la fois dans les numéros de version de Discourse et comme nom de branche Discourse. J’ai constaté que cela confondait certaines personnes.
« Bêta » effraie probablement certains utilisateurs semi-compétents en informatique comme moi : le sens habituel est « encore en phase de test pour la qualité » plutôt que « encore en cours d’ajout de fonctionnalités ».
Je pense surtout aux noms de version plutôt qu’au nom de la branche. J’avais supposé que j’étais sur une branche « bêta » d’après les noms de version (ce n’est pas le cas) jusqu’à présent, donc rien ne m’a rebuté…
Oui. Je pense que c’est déroutant (ou je peux voir comment cela pourrait être déroutant) que vous soyez sur tests-passed et que la version s’affiche comme « beta » mais que vous puissiez effectuer une mise à niveau et obtenir un nouveau code qui est la même version bêta sur laquelle vous êtes déjà. Et il y a des semaines et des centaines de commits entre les versions bêta.
