Meine Discourse-Installation ist veraltet (3.2.0.beta4-dev) und ich muss auf 3.5 upgraden. Ich befürchte, etwas zu beeinträchtigen, und verwende einige Plugins/Integrationen, die ich nicht ändern wollte (WP Discourse, Anmeldung über WordPress mit Mitgliedschaftsinformationen und der Category Lockdown-Plugin), und ich hatte in der Vergangenheit Probleme mit manuellen Upgrades.
Was ist der beste Ansatz für das Upgrade? Sollte ich zuerst eine Art Teil-Upgrade auf eine andere Version durchführen? Gibt es irgendwelche Fallstricke, auf die ich achten sollte?
Dies hat einige gute Nebeneffekte: Sie stellen sicher, dass Sie ein aktuelles Backup haben und eine sichere Kopie dieses Backups. Sie müssen diese Dinge tun, unabhängig davon, wie Sie Ihr Upgrade durchführen.
Ich habe den Eindruck, dass es eine gute Praxis wäre, auch alle Ihre Plugins auszukommentieren, aber es wäre gut, wenn jemand dies bestätigen würde.
Ja. Tatsächlich zu wissen, dass Sie einen neuen Server hochfahren und ein Backup wiederherstellen können. Ich musste dies kürzlich tun, als eine SSD eines meiner Server ausfiel. Ich wünschte, ich hätte tatsächlich geübt (obwohl es sich herausstellte, dass ich es nicht explizit geübt hatte, aber nachdem ich den Prozess Hunderte Male durchlaufen hatte, war es genug und alles lief wie geplant).
Es gibt keine Nachteile, insbesondere da eine Reihe von Plugins in den Kern verschoben wurden und es etwas Altes geben könnte, das kaputt ist. Nachdem das Ding funktionsfähig ist, können Sie die Wiederherstellung aller Plugins vornehmen, die Ihnen fehlen.
Best Practice? Führen Sie eine Checkliste, die Sie irgendwo ablegen können. Sie können eine in der Benutzeroberfläche hinzufügen adminupdate, indem Sie diesen CSS-Code zu Ihrem Theme hinzufügen (../admin/customize/themes/ editcss), falls Sie oder jemand anderes jemals die Idee hat, zu schnell ein Update durchzuführen:
.admin-contents.update .d-nav-submenu::before {content:“Update-Checkliste” : Backup erledigt? „ ; „Letzte Meta-Ankündigung gelesen? ; Wichtigste Bugs des letzten Monats von Meta geprüft? Wesentliche Plugin-Kompatibilität geprüft? Postgres/Redis-Kompatibilitätsversion geprüft? Richtiger Zeitpunkt für das Update geprüft? Fehlerbehebungs-Belegschaftsverfügbarkeit im Falle eines Update-Fehlers geprüft?“ }
Checklisten sind eine gute Idee. Ich persönlich, wenn ich über ein Upgrade nachdenke, warte auf eine Veröffentlichung, warte ein paar Tage, warte auf einen Wochentag, lese die Kategorien „Bugs“ und „Support“, um zu sehen, welche Probleme die Leute haben. Und warte darauf, dass diese Probleme, falls vorhanden, behoben werden.
Nein, ich bin auf tests-passed. Es stimmt, dass meine Verzögerung von ein paar Tagen es einigen weiteren Commits ermöglicht, zum Repository hinzugefügt zu werden, aber gleichzeitig ermöglicht es auch, dass einige Fehler korrigiert werden. Fast alle Commits sind natürlich nicht problematisch, daher denke ich, dass es ein guter Kompromiss ist, aber die Meinungen können auseinandergehen.
Es gibt eine Flut von Upgrades kurz nach einer neuen Beta, daher ist selbst bei bestandenen Tests ein paar Tage nach einem Upgrade ein guter Zeitpunkt für ein Upgrade. Oder vielleicht teilen wir die gleiche fehlerhafte Logik!
Ich glaube, Sie würden so etwas wie den Prozentsatz der Commits sehen, die fehlerbezogen sind (bin mir nicht sicher, wie man das quantifiziert – vielleicht einfach diejenigen zählen, die „FIX“ im Commit haben?) für die 5 Tage nach einer Veröffentlichung im Vergleich zum Prozentsatz für den Rest der Zeit.
