Il m’a fallu jusqu’à maintenant pour réaliser qu’il y avait un canal stable et que je devais modifier la configuration pour y passer.\n\nJe vois maintenant une option de mise à niveau vers 3.0.0.beta16 pour mes sites. Si je passe maintenant à la version stable et que je mets à niveau, cela ira-t-il vers 3.0.0.beta16 puis éventuellement vers la version stable 3.0.0 ?
Pouvez-vous expliquer pourquoi vous pensez devoir passer à la version stable ?
1 « J'aime »
Je ne vois pas pourquoi on aurait besoin d’une raison pour exécuter un logiciel stable. Je veux juste moins de mises à jour et un logiciel stable.
1 « J'aime »
Je ne pense pas. Si vous passez à stable, vous ne mettrez à jour que les versions majeures, et la 3.0.0 n’est pas encore sortie. La dernière version stable était la 2.8.0 (vous pouvez voir les dernières mises à jour dans release-notes)
Je ne pense pas que Stephen essayait d’être drôle. Stable est utilisé comme un mot-clé pour app.yml, pas comme un mot anglais. La raison étant que l’autre mot-clé (par défaut), tests-passed, peut également être décrit comme stable : il est peu probable qu’il soit cassé[1], et en fait, peut être plus « stable » (au sens anglais) si vous mettez à jour les plugins et/ou les composants de thème plus fréquemment que vous ne souhaitez mettre à jour Discourse.
au cours de mes 2 années d’utilisation de Discourse, je n’ai jamais eu une situation où quelque chose était cassé à cause d’un nouveau commit ↩︎
3 « J'aime »
Merci pour l’info ! Je sais qu’il n’essayait pas d’être drôle, il ne cherchait pas à discuter des raisons, juste des informations sur quand mettre à jour pour passer à la version stable. Je continuerai à mettre à jour tant qu’il le dira et je passerai dès que je verrai la 3.0.0 atteindre la version stable.
Soyez conscient que la sortie de la version majeure, à ma connaissance, sur une branche tests-validés s’accompagne de la sortie de n+1.beta1, donc si vous voulez éviter le mot « beta » dans votre version, vous devriez y basculer juste avant de passer à n+1.beta1.
Parfois[1] les questions sont formulées sur la base d’hypothèses erronées, et il est préférable de les comprendre tôt.
on pourrait soutenir que très souvent, si nous traitons de sujets du type « aidez-moi, s’il vous plaît ». ceci est, à mon humble avis, basé sur des discussions sur mon forum aussi ↩︎
1 « J'aime »
Par exemple, je suis actuellement sur la version 2.9.0.beta14. Je devrais changer la branche dans ma configuration pour « stable », puis simplement attendre que la version 3.0.0 apparaisse dans ma section /admin et qu’elle n’affiche que les mises à jour vers les versions stables à partir de ce moment-là ?
Lorsque je modifie le fichier de configuration, dois-je redémarrer le conteneur Docker ?
Vous pouvez modifier le fichier app.yml dès maintenant. Vous devrez attendre la sortie officielle pour exécuter une autre mise à niveau en ligne de commande. Il n’est pas clair combien d’autres versions bêta il y aura avant la sortie d’une nouvelle version stable.
Stable signifie moins de mises à jour, mais pas nécessairement moins de bugs. Cela demande un peu plus d’expertise pour exécuter la version stable que pour les tests réussis. Les mises à jour de sécurité critiques sont incluses dans la version stable, mais les problèmes d’interface utilisateur resteront probablement non résolus jusqu’à la prochaine version stable. Les plugins tiers sont moins susceptibles de fonctionner avec la branche stable car elle est moins bien testée.
Si vous souhaitez moins de mises à jour, vous pouvez simplement mettre à jour moins fréquemment.
4 « J'aime »
Une bonne explication de stable vs test-passed :
5 « J'aime »
Je dois admettre que je me sens sous pression et confus par la notification de mise à jour sur la page d’administration.
Elle me dit de manière plutôt abrupte que je devrais mettre à jour immédiatement, mais elle me dit de mettre à jour vers un logiciel bêta. C’est plutôt contradictoire. Je pense qu’elle devrait informer l’utilisateur qu’il y a une mise à jour, mais seulement pousser l’utilisateur à mettre à jour dès que possible s’il y a un problème de sécurité ou un bug critique dans sa version actuelle.
Peut-être que l’étiquette bêta pourrait être supprimée si elle est considérée comme stable ou changée en tests-passed afin que les administrateurs se sentent plus à l’aise pour mettre à jour, sachant qu’ils obtiennent un logiciel entièrement testé et stable.
Alternativement, elle pourrait abandonner l’étiquette bêta et être appelée stable, car c’est ce que je lis ici, puis la version stable actuelle pourrait être appelée LTS.
1 « J'aime »
C’est exactement ce qui se passe, lorsqu’une nouvelle bêta sort, il y a (presque toujours) un sérieux problème de sécurité qui déclenche la nouvelle version.
Ce serait en effet une façon assez bonne (meilleure, selon moi) de voir les choses.