Plugin versioning pattern/semver adoption

[jonasraoni]

Small discussion about versioning, here's the context: https://github.com/pkp/pln/blob/main/version.xml#L16

Sparing a range to avoid the versions to overlap (looks like we already have some cases) across different branches ends up breaking the versioning meaning... I'm used to have a unified version/branch and multi-target with the help of #ifdefs, so I'm not so sure what would be a good approach here. What else could we use?

• (Pre|Su)fixes: PLUGIN_VERSION-stable_3_3_0?
• An extra tag in the version.xml stating its compatibility <compatibility>ojs_3.3.*</compatibility> (probably useful for the plugin gallery)?
• ...?

Also, what about dropping the 4 digits version (w.x.y-z in favor of semver (it has room for pre-release and metadata tags)?

ctgraham
Yes to plugins declaring their compatibility within version.xml as a dedicated tag!

Note that this will soon be much easier as we can now support composer/semver constraint statements: #7793

p.s.: rescued from a Slack conversation

[marcbria]

Aunque a priori no se me ocurre ningún problema en cambiar de 4 dígitos a semver, comentar (por ver las ramificaciones) que las imágenes docker usan los mismos nombres de versión que las herramientas OxS.

[ctgraham]

Note that our Version object is now aware of semver.

If the plugin's version.xml contained a semver-based version declaration, and a semver-based compatibility declaration, then future entries in the Plugin Gallery would not need to re-produce this information by hand, and this information could be used during the installation process to sanity check the addition of plugins, even when unknown to the Plugin Gallery.