# Upgrading Discourse before upgrading plugins causes problems
**URL:** https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781
**Category:** Feature
**Created:** [April 28, 2017, 2:42pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781 "2017-04-28T14:42:25Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [April 28, 2017, 2:42pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/1 "2017-04-28T14:42:25Z")
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. . .)
---
### Author:  [@hutchinsfairy](https://meta.discourse.org/u/hutchinsfairy)
#### Post date: [April 28, 2017, 3:02pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/2 "2017-04-28T15:02:55Z")
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!
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [April 28, 2017, 3:45pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/3 "2017-04-28T15:45:30Z")
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.
---
### Author:  [@fefrei](https://meta.discourse.org/u/fefrei)
#### Post date: [April 28, 2017, 8:06pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/4 "2017-04-28T20:06:35Z")
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](https://meta.discourse.org/t/sending-notifications-is-slow-throws-exceptions/61193)
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 28, 2017, 9:16pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/5 "2017-04-28T21:16:28Z")
Is there an actual bug here @tgxworld?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [April 29, 2017, 12:09am UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/6 "2017-04-29T00:09:36Z")
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
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 29, 2017, 12:21am UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/7 "2017-04-29T00:21:23Z")
The web updater does block upgrade in the case where the _updater itself_ needs updating first, but not in other scenarios.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [April 29, 2017, 11:54am UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/8 "2017-04-29T11:54:13Z")
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.
---
### Author:  [@fefrei](https://meta.discourse.org/u/fefrei)
#### Post date: [April 29, 2017, 2:26pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/9 "2017-04-29T14:26:10Z")
If only there was a way to simply eliminate that choice 😬
> [@Discourse Docker Manager: Upgrade All](https://meta.discourse.org/t/discourse-docker-manager-upgrade-all/33808):
>
> The Docker Manager is great for keeping everything up-to-date, but it’s awfully slow when you have more than one thing that needs upgrading, not to mention that you need to restart the web server once for each plugin. I’d like to propose a new button called Upgrade All that would go through and upgrade everything in one quick run, similar to what a ./launcher bootstrap app does. Advantages Disadvantages Less user intera…
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [April 29, 2017, 3:01pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/10 "2017-04-29T15:01:20Z")
> [@pfaffman](#):
>
> it’s probably always best to upgrade plugins first
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!
> [@fefrei](#):
>
> after a failed upgrade, the container can be in a weird state, where it thinks it is upgraded although the upgrade did not complete.
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
> [@](#):
>
> Last update failed, click here to try again or try rebuilding the container
Maybe that’s something else that could be implemented in addition to an Upgrade All button.
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [April 29, 2017, 5:50pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/11 "2017-04-29T17:50:08Z")
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.
---
### Author:  [@Mittineague](https://meta.discourse.org/u/Mittineague)
#### Post date: [April 29, 2017, 10:34pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/12 "2017-04-29T22:34:18Z")
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.
---
### Author:  [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [April 30, 2017, 1:11pm UTC](https://meta.discourse.org/t/upgrading-discourse-before-upgrading-plugins-causes-problems/61781/13 "2017-04-30T13:11:31Z")
That would limit forum functionality during the upgrade. We aim for (and currently do) zero-downtime upgrades.