Mijn Discourse-installatie is verouderd (3.2.0.beta4-dev) en ik moet upgraden naar 3.5. Ik ben bang om dingen te verstoren en gebruik een paar plugins/integraties die ik niet heb willen veranderen (WP Discourse, inloggen via Wordpress met lidmaatschapsinformatie en de Category Lockdown plugin) en ik heb in het verleden problemen gehad met handmatige upgrades.
Wat is de beste aanpak om de upgrade uit te voeren? Moet ik eerst een soort gedeeltelijke upgrade naar een andere versie doen? Zijn er valkuilen waar ik rekening mee moet houden?
This has some good side-effects, of ensuring you have a recent backup and you have a safe copy of that backup. You do need to do those things, however you approach your upgrade.
I get the impression it would be good practice to comment out all your plugins too, but it would be good for someone to confirm that.
Yeah. Actually, knowing that you can spin up a new server and restore a backup. I had to do this once recently when one of my server’s had a SSD die. I wished that I had actually practiced (though, as it turned out, though I hadn’t explicitly practiced, having gone through the process hundreds of times was enough and it all went as planned).
There is no downside, especially since a bunch of plugins got moved to core and there could be something old that’s broken. After the thing is in working order, you can go about restoring whatever plugins you notice are missing.
Beste praktijk? Houd ergens een checklist bij, je kunt er een toevoegen in de UI adminupdate door deze CSS aan je thema toe te voegen (../admin/customize/themes/ editcss) als je ooit of iemand ooit het idee krijgt om te snel te updaten:
.admin-contents.update .d-nav-submenu::before {content:“Update checklist” : Backup gedaan?\" ; “Laatste maand meta-aankondiging gelezen? ; belangrijkste bugs van vorige maand van Meta gecontroleerd? Essentiële plugincompatibiliteit gecontroleerd? Postgres/Redis compatibiliteitsversie gecontroleerd? Juiste timing voor de update gecontroleerd? Probleemoplossingspersoneel beschikbaarheid in geval van updatefout gecontroleerd?” }
Checklists zijn een goed idee. Wat mijzelf betreft, die overweegt een upgrade, wacht ik op een release, wacht ik een paar dagen, wacht ik op een weekdag, lees ik de categorieën Bugs en Ondersteuning om te zien welke problemen mensen hebben. En wacht ik tot die problemen, indien aanwezig, zijn opgelost.
No, I’m on tests-passed. It’s true that my delay of a few days will allow some stray further commits to be added to the repo, but at the same time it allows some mistakes to have been corrected. Almost all commits, of course, are not problematic, so I think it’s a good tradeoff, but opinions may differ.
Er is een stortvloed aan upgrades vlak na een nieuwe bèta, dus zelfs bij geslaagde tests is een paar dagen na een upgrade een goed moment voor een upgrade. Of misschien delen we dezelfde gebrekkige logica!
Ik denk dat je, eh, iets zou zien als het percentage commits dat buggerelateerd is (niet zeker hoe je dat kunt kwantificeren - misschien gewoon die tellen met “FIX” in de commit?) voor de 5 dagen na een release vergeleken met het percentage voor de rest van de tijd.
