My Discourse installation has fallen out of date (3.2.0.beta4-dev) and I need to upgrade to 3.5. I am worried about disturbing things and use a few plugins/integrations that I haven’t wanted to change (WP Discourse, login through Wordpress with membership info and Category Lockdown plugin) and I have had issues manually upgrading in the past.
What’s the best approach to do the upgrade? Should I do some sort of partial upgrade to a different version first? Are there any gotchas I should be aware of?
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.
Best practice? Keep a checklist somewhere, you can add one in the UI>admin>update by adding this CSS to your theme(../admin/customize/themes/ edit>css) if someday you or someone would have the idea to update too quickly :
.admin-contents.update .d-nav-submenu::before {content:“Update checklist” : Backup done?" ; “Last month meta announcement read? ; last months most important bugs from Meta checked? Essential plugin compatibility checked? Postgres/Redis compatibility version checked? Right timing for the update checked? Troubleshooting Workforce Availability in case of update failure checked?” }
Checklists are a good idea. For myself, contemplating an upgrade, I wait for a release, wait a couple of days, wait for a weekday, read the Bugs and Support categories to see what problems people are having. And wait for those problems, if any, to be fixed.
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.
There is a flurry of upgrades just after a new beta, so even on tests-passed, a few days after an upgrade is a good time for an upgrade. Or, perhaps we share the same flawed logic!
I think you’d, uh, see something like the percentage of commits that are bug-related (not sure how to quantify that–maybe just count those with “FIX” in the commit?) for the 5 days following a release compare to the percentage for the rest of the time.
Making the graph is left as an exercise for the reader.
