Upgrading Discourse before upgrading plugins causes problems


(Jay Pfaffman) #1

Just attempted an upgrade from web interfacefrom 1.8beta10 to 1.8beta11 and plugin.rb:154 block in activate!. There was an "uninitialized constant warning and a wrong constant name warning up above. (Pardon the transcribed error messages, but a client did the upgrade on his laptop. . .)


(TomG) #2

I also just got this trying to upgrade staff notes. I then tried to update Discourse and got the same error. When I go back now to check they both appear to have been updated!


(Jay Pfaffman) #3

Now that I think about it, it makes sense that you’d need to upgrade the plugin first. If you do an ./launcher rebuild app it happens all at once.


(Felix Freiberger) #4

You should run a rebuild – after a failed upgrade, the container can be in a weird state, where it thinks it is upgraded although the upgrade did not complete.

I also ran into this:


(Jeff Atwood) #5

Is there an actual bug here @tgxworld?


(Jay Pfaffman) #6

I don’t think so. You need to upgrade the plugin before you upgrade discourse. If there’s a bug, is that you should be required to upgrade plugins first


(Jeff Atwood) #7

The web updater does block upgrade in the case where the updater itself needs updating first, but not in other scenarios.


(Jay Pfaffman) #8

Yup. I knew it would make you upgrade Discourse-docker first. . .

I was with a client. “What should I upgrade first, Discourse, or the plugin?”

“Oh, it doesn’t matter.”

Doh!

I think that it’s probably always best to upgrade plugins first. A note to that effect is probably a good idea.


(Felix Freiberger) #9

If only there was a way to simply eliminate that choice :grimacing:


(David Taylor) #10

Not always - what if the new version of the plugin depends on features only available in the latest version of Discourse :grimacing:

When I want to upgrade and can’t be bothered to wait for every individual plugin to upgrade separately, I SSH into the server, enter the container, do a manual git pull in every plugin directory, then hit the “upgrade” button for Discourse itself in the UI, which updates everything simultaneously. But that’s clearly not a good UX!

This is an annoying problem which I’ve hit a few times - as far as I can tell there’s no indication in docker-manager that the upgrade failed, even though asset compilation failed. All it needs is a warning at the top saying something like

Maybe that’s something else that could be implemented in addition to an Upgrade All button.


(Michael - DiscourseHosting.com) #11

There really should be a better mechanism to manage plugin compatibility, since I can give numerous examples where updating the plugins first will also fail.

plugin.rb could contain optional min_version and max_version fields, and the updater could search for a suitable commit.
Alternative solution would be to use tags on plugins that correspond with compatible Discouese versions.


(Mittineague) #12

In terms of plugins causing problems, I’m thinking it’s not so much about the upgrade sequence as it is the plugins being installed/enabled at the time of the upgrade.
That is, if the steps were:

  • disable all plugins
  • rebuild
  • upgrade Discourse
  • upgrade plugins
  • enable plugins
  • rebuild

that even if a plugin was broken, Discourse would at least have upgraded successfully.


(Michael - DiscourseHosting.com) #13

That would limit forum functionality during the upgrade. We aim for (and currently do) zero-downtime upgrades.