Geef pluginversies voor minimale en maximale discourseversie

Functie
1

Ik vraag me af of we plugins een versienummer kunnen geven om de minimale en maximale versie van discourse waarmee het compatibel is, te kunnen weergeven.

Zodat we niet tegen de situatie aanlopen dat onze plugin is bijgewerkt, maar onze discourse-versie achterliep en dan de hele site breekt.

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.

7 likes
3

Ik weet niet zeker hoe ik een maximale compatibele versie voor een plugin zou kunnen definiëren. Een eenvoudige plugin zou waarschijnlijk kunnen zeggen dat deze tot ten minste 4.0 werkt, en wanneer 4.0 arriveert, kan deze nog steeds werken omdat CDCK geen compatibiliteitsonderbrekende wijzigingen heeft geïntroduceerd.

Maar misschien gebruikte de eenvoudige plugin iets dat CDCK in 3.8 als verouderd markeerde en in 3.10 verwijderde… Erg moeilijk om hier rekening mee te houden.

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