Specifically for 3.4.0.beta4 -- what are the system requirements?

Support
1

I don’t want to run into upgrade problems like Update “3.4.0.beta4” failed or Upgrade failed spectacularily – or the email-related problems like Severe Email Issue since last update a couple days ago - 3.4.0.beta4-dev or Severe Email Issue since last update a couple days ago - 3.4.0.beta4-dev or 550-Requested action not taken: mailbox unavailable on 3.4.0.beta4-dev.

I’ve seen PostgreSQL 15 update which suggests that in an ideal world I’d just need to ./launcher rebuild app twice (and has some optional commands to run afterwards). It does have the warning of needing 2x database size of extra disk space “if your database is very large” (maybe that extra space is required even for a small database?)

Is there a list of requirements or specific instructions for this upgrade?

2

If you have disk space and an up-to-date docker, you will probably be fine.

If you have an out of date OS, and that makes you have an old docker, you should spin up a new VM and move to it as described at Move a Discourse site to another VPS with rsync.

I’m pretty sure that at least most of the people who have had trouble have out of date Docker versions, most of which are caused by out of date OS versions.

If you spin up a new VM then nothing can go wrong since your old server will still be available.

3 Likes
3

Ok I’ll try that. I think a couple of the disasters here were with Docker versions between “deprecated” and “minimum” (as I am).

4

I suspect that’s true. It’s pretty hard to figure out just what version is the exact problem. I upgraded 10 or so sites today. The ones with current docker all worked just fine.

5

I would have done that but didn’t think those instructions were sufficiently idiot-proof. My approach was:

  • Read only mode on.
  • Backup Discourse from admin interface.
  • Digital Ocean snapshot.
  • sudo apt update, sudo apt upgrade, sudo do-release-update twice (20.04 to 22.04, then to 24.04).
  • Update Discourse as normal (twice, for the Postgres update).
1 Like
6

That’s great!

I consider the other instructions much more idiot proof. If something goes wrong, your existing site just keeps working. If something had gone wrong on either of your do-release-update steps you’d just have to keep restoring to your most recent snapshot.

There are lots of ways to do things, though.

1 Like
7

More than one way to skin a cat!

By “idiot proof” I was meaning the instructions themselves, e.g. which flags to use for rsync (there were various suggestions), which set of instructions to follow (there were at least three).

I can see your point of view, which is that an idiot (if he could follow the instructions) would be better off doing it the rsync way. I would have rather done it that way for the reasons you gave, but I just didn’t trust myself to make the right decisions.

If I’d had to restore from the snapshot I might have tried it next!

1 Like