Replies: 2 comments
-
I'm using it as the minimum requirement for my plugins. .. BUT I thought it would be enforced. :/ ...
I think, that would be good. |
Beta Was this translation helpful? Give feedback.
-
Thanks @saqimtiaz @pmario I think you've stumbled on our longest standing bit of cargo culting. I do have a faint memory of writing code to enforce core-version checks on plugins, but evidently it was dropped if it was there at all.
I was slightly surprised to discover that there's no enforcement at the moment.
Ouch. The idea was to support the semver comparisons that npm supports (https://github.com/npm/node-semver).
I think that that would indeed tie the plugin to a particular core version number.
It seems like a good idea, but I do wonder whether it would be worth the effort.
Yes; if we decide not to enforce it, it still seems perfectly reasonable for us to keep it as an advisory field for humans.
Hmmm so we'd have something like |
Beta Was this translation helpful? Give feedback.
-
End-user and developer documentation suggests that plugins should have a
core-version
field with examples for values being>=5.0.8
and>=5.0.0
Is this enforced as a requirement during import by drag and drop or when installing via a plugin library? It isn't as far as I can tell but perhaps I am missing something. Neither is this information visible to users while installing plugins via a plugin library or via drag and drop.
Furthermore, attempts to check for core-version compatibility with wikitext are not particularly easy since the
compare[]
operator for typeversion
does not support patterns like>=5.1.0
.core-version
field with value5.1.23
is it meant to suggest that this the minimum core version, or that the plugin works with precisely that core version?core-version
field during the plugin installation process?>=5.1.0
?Beta Was this translation helpful? Give feedback.
All reactions