Give Plugin versions for minimum and maximum discourse version

Feature
,
1

I am wondering if we can give plugins a version number to allow plugin list the minimum and maximum version discourse it is compatible with.

So we don’t run into the instance when our plugin updated, but our discourse version was behind and then it breaks the entire site.

2

There’s two broad classes of plugins and TC’s:

  • Official
  • Third Party

Official plugins already maintain compatibility, and if they are not compatible, you usually have a salaried developer fixing things within days.

3rd Party Plugins

It is already hard enough for maintainers to keep things compatible, let alone keep track of whether they are or not.

There are really only two versions that are practical to maintain against:

  • latest stable
  • latest tests-passed

You can use the pinning system (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) to pin for stable already. Might be quite nice to surface that somehow to show explicit compatibility, but it doesn’t mean the plugin is not compatible if there is no pin.

Compatibility with latest might be surfaced with a green tick from CI on github.

That relies on two things:

  • a thorough CI setup (ideally based on the Discourse plugin standard)
  • very high test coverage

The latter is a big ask for 3rd party maintainers doing things for free.

For unofficial plugins, your feature request boils down to decent funding of third-party plugins.

As a seasoned plugin author that’s been around the block I can tell you that it’s almost impossible to fund 3rd party plugins.

The only reason my plugins still work is because:

  1. I use them
  2. As a means of maintaining reputation in the ecosystem.

That’s valuable to me but has its limit.

I’d say that 3rd party plugin development is close to :skull: in the Discourse ecosystem, with only a very small handful of developers able to keep things working against the very demanding velocity of core.

Other exceptions:

  • plugins used by major hosts like Communiteq - perhaps they have an opinion - but even they have to focus on what most clients want and there will be limits to their resources too.
  • the Custom Wizard & Events plugins that have a subscription system attached - again you can get an opinion from Angus on where that is going.

Summary

Given then that you can only really rely on official plugins being compatible (and perhaps a handful of additional ones from very active developers like myself or Communiteq), I suggest you simply focus on using the official plugins and for those I think your feature request is redundant because a process is in place for those things to keep track of core.

6 Likes
3

I am not sure how I would be able to define a max compatible version for a plugin. A simply plugin could probably say it works up to at least 4.0, and when 4.0 comes around, it might still work because CDCK didn’t introduce any breaking changes.

But maybe the simply plugin used something which CDCK deprecated in 3.8 and removed in 3.10… Quite difficult to take this into account.

4

Because you can’t.

It will be out of date as soon as the next commit is released.

But it’s simple:

  • Exhaustive (95% coverage) plugin tests (back end and system min) run on every new commit of core in CI

Then check for green tick before installing.

5

I’ve been playing around for this and came up with a solution in Github.

So just a green tick for for the most recent CI job isn’t good enough, as things might have changed in recently, which might break the plugin. Basically you need to re-run the CI jobs when Discourse updates branches.

In this example repository I worked out an efficient solution. It is basically a scheduled workflow which checks the important branches of the Discourse repo so see if there are changes, if there are it will trigger the normal CI workflow which should run the test suite. In you’re readme you can then place some badges to show how does CI workflows ran against the most recent changes.

The monitoring workflow runs in seconds. So when scheduled it would only consume 1 minute of github action time.

Obviously the reliability of this whole setup depends on the plugin/theme-component developer’s effort of creating a good test suite.

And you still have the UX issue that from Discourse’s “update” page you don’t know if the most recent CI job failed for a specific version.

So besides having a monitoring workflow which rebuilds a plugin when the Discourse branch changes, you need to create a build artifact recording the result (pass/fail). In your plugin metadata you should be able to point to this artifact, and discourse should retrieve this artifact to display the compatibility/result in the update interface.

It is not a foolproof construction, but it’s something.

6

that’s why I wrote “on every new commit of core in CI” :wink:

we had a dashboard on Pavilion for a long while that did exactly all this