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. . .)
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!
1 Like
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.
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:
https://meta.discourse.org/t/sending-notifications-is-slow-throws-exceptions/61193?u=fefrei
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
2 Likes
The web updater does block upgrade in the case where the updater itself needs updating first, but not in other scenarios.
1 Like
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.
If only there was a way to simply eliminate that choice 
3 Likes
Not always - what if the new version of the plugin depends on features only available in the latest version of Discourse 
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.
1 Like
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.
1 Like
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.
That would limit forum functionality during the upgrade. We aim for (and currently do) zero-downtime upgrades.
3 Likes