Plugin versioning pattern/semver adoption #8017
Replies: 2 comments
-
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. |
Beta Was this translation helpful? Give feedback.
-
Note that our If the plugin's |
Beta Was this translation helpful? Give feedback.
-
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:
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):w.x.y-z
) in favor ofsemver
, 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
Beta Was this translation helpful? Give feedback.
All reactions