Compatibility checks and stable versioning for plugins

(Erlend Sogge Heggen) #1

This recently came up:

There’s got to be a better way to do this. It seems very wrong to neglect users who’ve chosen to stay on the Stable updates branch.

Some options:

1 - Plugins have “stable” and “beta” branches as well.

Quite simply, once you begin working on a plugin against a beta-version of Discourse, you could do so in the plugin’s respective beta-branch.

2 - Plugins expose version-compatibility

I don’t know how realistic this is, but I was thinking it might be possible to put this type of meta-data in the plugin.rb or something such, similar to the Requires at least: 3.8 and
Tested up to: 4.3 in a WordPress plugin’s readme.txt.

Smoke-testing plugins during upgrade process
You can now install Discourse on DigitalOcean via Bitnami
Associating plugin versions with Discourse versions
Native theme support
Babble - A Chat Plugin [ARCHIVE]
Discourse Docker Manager: Upgrade All
Installing a particular commit of a plugin?
A new versioned API for client side plugins
How are you nurturing an ecosystem of “Specialised contractors”?
(Tom Newsom) #2

Option 1 seems most workable

(Gerhard Schlager) #3

I think option 2 should be a must, option 1 should be a recommendation for plugin developers.

(Alan Tan) #4

On a related note, I think being able to write tests (integration and unit) and run them against a certain release of Discourse would be helpful as well.

(Mittineague) #5

It would be nice t have code dealing with versions.

IMHO the easiest “work-around” would be to add a “tested with Discourse ver ___” or “known to work Discourse ver ___” type of field in the plugin lead along with the name, description, plugin page link, etc

And maybe a “plugin ver release” date too.

It would still mean Admins would need to look and think “OMG, I’m way past that version / date, I better check the plugin’s source page for recent updates” but it would be something.

(cpradio) #6

Just for the record, I’m not a fan of Option #1, simply for, as a plugin developer, me trying to maintain and figure out when Discourse merges from master, to tests-passed, to beta, to stable is near impossible (since it happens across many months). Trying to do that with 1 plugin, let alone 7 of them would be a nightmare.

It would be far better for plugins to denote what they are known to be compatible with, and Discourse could then choose not to load said plugin if it is deemed incompatible. Additionally, it would be nice if the plugin could execute some “safe” code to disable any settings that may cause the Discourse instance to break.

(Jeff Atwood) #7

Hmm good point looks like option 2 is what @eviltrout chose :wink:

(cpradio) #8

Yes, for, the API. I still think it would be nice to do this on an entire plugin level to the Discourse version. So although we can now control the API we interact with, showing whether or not we’re compatible with the version of discourse they are running (for when things not related to the dom, such as hooks, plugin outlets, routes, models, et al are needed).

So I definitely agree with the process used with the API. I would like to see it extend further though :slightly_smiling:

1 Like
(Sam Saffron) #9

We already technically support option 1, you would just point the plugin at a different branch, but its a headache to manage.

My vote is for option 2:

I think we should probably add a “versions” file as metadata, imagine if we allowed this kind of file to be checked in to plugins repository:


1.4: 1e8098ba055

Then docker manager can always check this file, if it has the file it can checkout the the correct version.

This means that we don’t need to worry about making branches and cherry picking into branches and so on, fixing an incompatibility becomes trivial.

Building this is a bit of a headache though and none of our hosting is impacted by this problem which is something to keep in mind.

(ljpp) #10

I totally :heart: Discourse, but I have to say that the way that you guys manage the branches is quite unorthodox, and unlike anything I’ve seen before. I’ve worked 12 years making smartphone OS software, so I’ve seen a fair share of branch management, I can promise you that.

The stable branch should be the product you are delivering, with the optional plugins included. This is a much needed improvement in order to prevent plugin breakage, which currently happens even in the beta branch.

(Robin Ward) #11

I don’t think this is fair. If you’re referring to the incident with the AdSense plugin, I’m not sure you understand that it’s a third party plugin. We can’t possibly maintain compatibility with every piece of software that relies on Discourse.

I recently went through and upgraded our Plugin API in a big way to make sure backwards compatibility would be better going forward. During this process, I actually went out of my way to send pull requests to many third party plugins include the one that broke. Personally, I think this is above and beyond what is normally required from software developers, but I wanted to make sure that everyone was ready.

In the case of the 3rd Party Adsense plugin, my pull request actually had a bug which caused it to break on the beta branch. Once you pointed it out, I promptly fixed it.

The bug was 100% located in the 3rd party plugin, not Discourse.

If you could stop criticizing our beta branch for not working, I would appreciate it. This is the second time you’ve done it mistakenly.

I recommend you stick with the stable branch and only first party, authorized Discourse plugins if you have no tolerance for bugs.

(Michael - #12

(For the record: this is not meant as criticism - you did indeed go out of your way fixing our plugin, which is very highly appreciated !)

But @ljpp does have two good points here:

  1. Stable is not updated very often, which is a pity.
  2. It would be really cool if a plugin had some kind ‘last working version’ meta data, which automatically disables a plugin in case the Discourse version is too new. Right now, a Discourse plugin can still break Discourse if Discourse is updated and the plugin wasn’t prepared for that). You can’t maintain compatibility with every plugin, but in that way plugins would be able to make sure they don’t break Discourse. I can’t find the thread anymore, but @rgj and I proposed such a mechanism about two years ago.

The combination of these two things causes a lot of people being on beta, and plugin devs are unable to prepare for breaking changes on beta. Having some kind of meta data would solve this pretty well.

(ljpp) #13

I actually thought that AdSense is 1st party or officially supported pluging. I even thought that @michaeld is a part of the core team. So my bad there.

But when I wrote what I wrote, I was not actually thinking about my incident specifically, but the fact that such situation is even possible. That is a serious issue in terms of branch/release robustness and therefore the proposed improvements in this thread are very welcome. The whole point of branched releasing in general is to mitigate such risk scenarios.

Keep up the good work! :muscle:

(Mittineague) #14

If every plugin was required to have full code coverage acceptance tests pass or else be disabled that could help a lot.

But you can get an idea of how well that would go over with plugin devs

I think the only sane way to approach it is for Admins to

  • save a backup
  • disable all third party plugins
  • update
  • enable third part plugins one by one checking for breakage

Or else deal with the fact that breakage might happen

1 Like
(Simon Cossar) #15

Something like:
# compatibility: <=1.7.1
could be added to the plugin manifest. If an attempt was made to install a plugin on a higher version of Discourse it would be aborted. Possibly the plugin author could also be notified.

(Jeff Atwood) #16

I believe @eviltrout has proposed something like this in the past?

1 Like

Sorry to bump this thread. Has any progress been made regarding what is discussed here? Is it on the roadmap for a future version?

I recently came accross this topic after an update of the Babble plugin that broke Discourse stable. Fortunately, a new stable version was released a week later but this could have been avoided with a simple compatibility header to hold off the plugin update.

1 Like
(Sam Saffron) #18

No concrete plans to build anything official into the plugin metadata. However for official plugins if we break them against stable we will create a stable branch so you can consume that instead.

All official plugins always work against tests-passed. If not then they are fixed asap.

1 Like
(Ismael Posada Trobo) #19

Hi guys,

What about to follow a similar Drupal’s approach? It means, tag plugins according to the stable versions they work for.

For instance, let’s assume we have the official plugin GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse tagged as 2.x-0.3. This means that this plugin, is stable and functional for all versions from 2.0.x to 2.9.x, and the plugin version itself is 0.3.

If for some reason a plugin is only stable for a specific version, a tag like 2.2.x-0.3 could warn users about :warning: ‘hey guys, do not try this plugin out on Discourse versions 2.1 or lower because it might crash your instance’ :warning:.

Dunno, it’s my opinion, and I think is informative enough for users.