J’avais un problème de longue date avec une installation Discourse qui était bloquée à la v2.9.0.beta1 — en raison de défis personnels, je n’ai pas pu le résoudre pendant des années. À l’époque, il semblait impossible de passer à la v2.9.0.beta2. Récemment, tout en dépannant un problème de reconstruction, j’ai commenté certains hooks dans mon app.yml (spécifiquement, ceux qui forçaient un checkout de tag) comme ceci :
Après la reconstruction, mon instance s’est mise à jour de manière inattendue vers la 3.4.0.beta4-dev. Bien que je sois heureux d’avoir résolu ce problème, je souhaite maintenant que le système continue de suivre le flux bêta 3.4.0 jusqu’à ce qu’une version stable 3.4.x soit disponible — et une fois qu’elle le sera, je veux la verrouiller sur cette version stable afin qu’elle ne se mette pas à jour automatiquement vers d’autres versions bêta ou de développement.
Quelle est la méthode appropriée pour « épingler » ou verrouiller la version à une version stable une fois qu’elle est disponible, sans avoir à annuler ou à effectuer des interventions manuelles à chaque reconstruction ?
Toute aide ou meilleures pratiques serait grandement appréciée !
Il semblerait que vous ayez changé la version en stable après la reconstruction. Vous êtes au-delà de la version stable maintenant, vous devrez donc la changer en beta ou tests-passés jusqu’à la prochaine version stable (et comme il y en a eu une la semaine dernière, ce sera dans un bon moment (typiquement 8-10 mois)
Non, malheureusement, je ne l’ai pas fait… J’en suis absolument certain, c’était sur 3.4.0.beta4-dev, puis j’ai modifié app.yml et j’ai reconstruit. Ensuite, 3.5.0.beta1-dev est apparu. C’est exactement le chemin suivi… Je n’ai aucun doute, pour être clair. J’ai littéralement vérifié les choses avant les actions que j’ai notées.
Merci encore pour votre aide @pfaffman. Pour résumer ma compréhension actuelle :
Notre instance fonctionnait avec 3.4.0.beta4-dev, ce qui n’est pas considéré comme une version stable.
Lorsque j’ai mis à jour ma configuration pour utiliser version: stable (avec la valeur par défaut commentée), je m’attendais à ce que les futures reconstructions verrouillent l’instance sur la branche stable. Cependant, comme nous étions déjà sur une version bêta, la mise à jour a continué, résultant en 3.5.0.beta1-dev.
Il semble que passer à version: stable après avoir dépassé la balise stable ne déclenche pas de retour arrière ; cela signifie simplement que si nous étions au niveau ou en dessous de la version stable, cela nous épinglerait à la version stable au lieu de suivre les versions bêta.
Est-ce correct ?
De plus, pourriez-vous clarifier quel est le processus recommandé pour nous assurer de ne pas suivre accidentellement le canal bêta à l’avenir ? Spécifiquement :
Laisser version: stable comme configuration active est-il suffisant pour garantir que, lorsqu’une version stable sera disponible, nos reconstructions s’y verrouilleront, à condition que nous ne l’ayons pas déjà dépassée lorsque la version stable arrivera ?
Y a-t-il des étapes supplémentaires ou des tâches de nettoyage (telles que la suppression ou la modification d’autres éléments de configuration) que nous devrions effectuer pour éviter de mettre à jour par inadvertance vers des versions bêta/de développement ?
Je souhaite vraiment me verrouiller sur une version stable dès que possible, mais je ne veux pas que cela me dépasse à nouveau…
Mince ! J’ai peut-être regardé trop vite sur mon téléphone. Je n’ai aucune explication sur la façon dont j’ai manqué cela ni sur la façon dont le site exécute maintenant la version 3.5.0.beta1-dev.
Après avoir subi les affres de la mise à jour 3.4.0.beta4-dev liée au passage de postgres 13 à 15, j’ai réussi à récupérer une version fonctionnelle 3.5.0.beta1-dev !
Maintenant, dans le tableau de bord, il y a une nouvelle version :
