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 adapt the code to work on other places with the help of "#ifdefs", but that's not suitable for our use-case, the version for 3.4 might have more features than the one for 3.3 for example, and they can co-exist for a long time.

Ideas:

• An extra tag in the version.xml stating its compatibility, which is useful when installing the plugin, and can be also re-used by the plugin gallery (instead of adding the such information on the plugins.xml):

  <compatibility application="ojs">
   <version>~3.4.0.0</version>
  </compatibility>

• Drop 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.