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!
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
Is there an actual bug here @tgxworld?
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
The web updater does block upgrade in the case where the updater itself needs updating first, but not in other scenarios.
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
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.
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.
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.