Plugin Version Compatibility

[medwards]

Is there any straightforward way to determine what versions of NodeBB a particular version of a plugin is compatible with? Or vice-versa?

I'm still running a roughly v0.3.2 version of NodeBB and when I do a clean "npm install" I get a version of the nodebb-widget-essentials plugin that crashes the process.

[julian]

Hey @medwards -- right now? No, and that's something that really needs to be resolved before we move forward, since we can't keep telling people to update to the latest version of NodeBB just for a specific plugin.

I'm entertaining ideas from the community...

• Should individual plugins report their compatibility in their package.json?
• Should we maintain a public registry and have plugin authors register their plugin/compatibility data?

[finid]

@julian

I think we need to start with making the installation process pull a specific stable version, preferably the very latest stable version, during the installation process. So if NodeBB 0.3.2 is the latest stable version and I'm doing a new installation, I should be git-pulling that version during installation, not the Edge version. Once that's done, users should be discourage from running Edge on a production system.

Then we can ask plugin authors to specify what version of NodeBB their plugin is compatible with. That will help clean things up a little bit.

[dwn]

Is there a methodology to write plugins according to the latest edge standards, but be backwards compatible? Something like a version global var for determining code flow?

[frissdiegurke]

@julian said:

• Should individual plugins report their compatibility in their package.json?
• Should we maintain a public registry and have plugin authors register their plugin/compatibility data?

I'd prefer the first since the second would need an additional build-step for the developer.
At least if you don't want the data to be within plugin.json and theme.json which would need way more effort than using engines-attribute I guess (didn't use this attribute yet but the description seems to fit the use-case).

[Schamper]

@dwn said:

Is there a methodology to write plugins according to the latest edge standards, but be backwards compatible? Something like a version global var for determining code flow?

This is simply impossible when plugins have a certain level of complexity and size. I'd seriously hate it if I'd have to backport the 0.4.x compatible Shoutbox to 0.3.2...

[dwn]

@Schamper An alternative perspective is that your 0.4.x-compatible code becomes outdated, and you simply add a condition to continue supporting 0.4.x when you fix it to work with 0.5.x

[julian]

@frissdiegurke said:

At least if you don't want the data to be within plugin.json and theme.json which would need way more effort than using engines-attribute I guess (didn't use this attribute yet but the description seems to fit the use-case).

I thought so too, although I wasn't sure if it actually worked, or if you can only use the "engines" field for node and npm versions.

I've also looked into using the "peerDependency" property in package.json, although that depends on NodeBB being installed via npm, which at the moment, it is not.

[Schamper]

@dwn said:

@Schamper An alternative perspective is that your 0.4.x-compatible code becomes outdated, and you simply add a condition to continue supporting 0.4.x when you fix it to work with 0.5.x

I'd have a few hundred conditionals by now though.

[Scuzz]

You could just leave the older versions compatible with the older versions of NodeBB. Like currentlyat BitBangers, we have the old 0.0.6 version running as that was the only one i could get working correctly with the 0.3.2 version of NodeBB.

If you use an older version of nodebb then you will have to use an old version of the plugin.