Le Tue, 20 Sep 2016 17:02:56 +0200 (CEST)
Johan Cwiklinski <jcwiklin...@teclib.com> a écrit:

>Hello all,


>I was thinking about plugins versions and compatibility... And that
>sounds like a nightmare to me :) I have questions, and maybe some
>ideas, here it is.
>First, some plugins versions contains a GLPi version (like 0.90-1.0);
>what is the inital goal of that? This version of the plugin can be
>compatible with GLPi 0.85, 0.90 and 9.1 - that does not make sense to
>me. Why not rely on a "simple" semantic versionning for plugins? Even
>if it is not directly related to GLPi itself, I guess we should
>provide some "good practices"; plugins maintainers can follow... Or
>not, of course. And if there is any good reason to keep GLPi version
>here, well... Which one? The minimal? The actual stable? Or even
>worse, both?

It's me introduce this version number because in old versions of
GLPI, a plugin is only compatible with a major version of GLPI. Since
0.85, plugins are compatible 0.85 & 0.90. 

For example, I have plugins compatible 0.85/0.90 not compatible with 9.1

>Second, we do not seem to have any efficient way right now to know if
>a plugin is compatible with a specific GLPi release. Each plugin do
>that (or not!) on its own side.
>Some plugins do not check any maximum version, saying they are
>compatible with any future release. That cannot be true, or that would
>prevent us to make any change regarding the whole plugin system (or
>maybe it is perfect already? ;)). Some other check a maximal version,
>which would be - for 9.1 compatible plugins - set to "9.2". OK. So, it
>is not possible to make any changes in the plugins system on the whole
>9.1 lifecycle? Maybe that would be the case, but maybe not... What if
>we have to fix an issue in 9.1.2 that would affect plugins system in
>one way or another? All plugins will say they're compatible, but may
>not. And plugin must be updated when the 9.2 release will be done,
>even if anything has changed. Well, I agree that the plugin system
>_should_ not change at all in the 9.1 lifecycle ;)

It's difficult to manage that. In most cases, a fix 9.1.2 will fix only
bug, so very few changes it affect plugin, or in good way, not in bad.

>I guess we cannot rely on next version, since it is not possible to
>know what this version would provide (some say they can, I do not
>believe them :D).
>For another project, I've set a "COMPAT" version, totally unrelated to
>current software version. It is a kind of "plugin system version".
>When this version is bumped on the core side, all plugins must be
>updated, old versions are disabled. Until this particular version is
>bumped, plugins are still "compatible", even if several minor and/or
>major versions has been released. Of course, if changes are made, but
>the version is not bumped, plugins will not work correctly. And that
>does not prevent plugins to be updated just to bump the compat,
>because it does not use parts of the core that have changed... This
>solution is not perfect at all, but maybe it could be a little better
>than what we have now.

Perhaps, not really opinion on it because not sure we can find a very
good way to manage it

>And, oh... Of course, plugins should not be in charge of checking
>that, the core itself should to this job (at least, to be sure
>something is really checked in a standardized way).

For the moment, each maintainer of plugins manage like he want :p
Perhaps manage it in other way with guidelines, but require document it
too ;)


>Any thoughts?

Glpi-dev mailing list

Reply via email to