Ich hatte ein langjähriges Problem mit einer Discourse-Installation, die bei v2.9.0.beta1 feststeckte – aufgrund persönlicher Herausforderungen konnte ich es jahrelang nicht beheben. Damals schien es unmöglich, auf v2.9.0.beta2 zu wechseln. Kürzlich, während der Fehlersuche bei einem Rebuild-Problem, habe ich bestimmte Hooks in meiner app.yml auskommentiert (insbesondere die, die einen Tag-Checkout erzwingen), wie folgt:
Nach dem Rebuild wurde meine Instanz unerwartet auf 3.4.0.beta4-dev aktualisiert. Obwohl ich froh bin, dieses Problem gelöst zu haben, möchte ich nun, dass das System den 3.4.0-Beta-Stream weiterverfolgt, bis eine stabile 3.4.x-Version verfügbar ist – und sobald dies der Fall ist, soll es auf diese stabile Version fixiert werden, damit es nicht automatisch auf weitere Beta- oder Entwicklungsversionen aktualisiert wird.
Was ist die richtige Methode, um die Version auf eine stabile Version zu „pinnen“ oder zu sperren, sobald sie verfügbar ist, ohne bei jedem Rebuild Rückgängig-Schritte oder manuelle Eingriffe durchführen zu müssen?
Jeder Rat oder Best Practices wäre sehr willkommen!
Es scheint, dass Sie die Version nach dem Rebuild auf stabil geändert haben. Sie sind jetzt über stabil hinaus, daher müssen Sie sie auf Beta oder Tests-bestanden ändern, bis zur nächsten stabilen Veröffentlichung (und da es in der letzten Woche eine gab, wird es ziemlich lange dauern (typischerweise 8-10 Monate)
Nein, leider nicht… Ich bin mir da zu 100 % sicher, es war auf 3.4.0.beta4-dev und dann habe ich app.yml geändert und dann den Rebuild durchgeführt. Dann erschien 3.5.0.beta1-dev. Das ist zu 100 % der Weg, der verfolgt wurde… Ich habe NULL Zweifel, nur um das klarzustellen. Ich habe die Dinge buchstäblich überprüft, bevor ich die von mir genannten Aktionen durchgeführt habe.
Vielen Dank nochmals für Ihre Hilfe, @pfaffman. Um mein aktuelles Verständnis zusammenzufassen:
Unsere Instanz lief mit 3.4.0.beta4-dev, was keine stabile Version ist.
Als ich meine Konfiguration auf version: stable (mit auskommentiertem Standardwert) aktualisierte, erwartete ich, dass zukünftige Rebuilds die Instanz auf den stabilen Zweig beschränken würden. Da wir uns jedoch bereits auf einer Beta-Version befanden, wurde das Update fortgesetzt, was zu 3.5.0.beta1-dev führte.
Es scheint, dass der Wechsel zu version: stable, nachdem wir bereits über den stabilen Tag hinaus fortgeschritten sind, kein Rollback auslöst; es bedeutet lediglich, dass wir, wenn wir uns auf oder unterhalb des stabilen Stands befunden hätten, auf stabil fixiert würden, anstatt Beta-Versionen zu verfolgen.
Ist das korrekt?
Könnten Sie außerdem den empfohlenen Prozess erläutern, um sicherzustellen, dass wir in Zukunft nicht versehentlich dem Beta-Kanal folgen? Insbesondere:
Reicht es aus, version: stable als aktive Konfiguration beizubehalten, um sicherzustellen, dass unsere Rebuilds sich daran halten, sobald eine stabile Version verfügbar ist – vorausgesetzt, wir sind nicht bereits darüber hinaus fortgeschritten, wenn die stabile Version eintrifft?
Gibt es zusätzliche Schritte oder Bereinigungsaufgaben (wie das Entfernen oder Ändern anderer Konfigurationselemente), die wir durchführen sollten, um versehentliche Updates auf Beta-/Entwicklungsversionen zu vermeiden?
Ich möchte so schnell wie möglich auf eine stabile Version umsteigen, aber ich möchte nicht wieder darüber springen…
Hoppla! Vielleicht habe ich auf meinem Handy zu schnell geschaut. Ich habe keine Erklärung dafür, wie ich das übersehen habe und wie die Seite jetzt 3.5.0.beta1-dev läuft.
Nachdem ich die Probleme des Updates 3.4.0.beta4-dev im Zusammenhang mit dem Wechsel von PostgreSQL 13 auf 15 überstanden hatte, konnte ich eine funktionierende Version 3.5.0.beta1-dev wiederherstellen!
