Le 21/09/2016 à 11:44, David DURIEUX a écrit :
Le Tue, 20 Sep 2016 17:02:56 +0200 (CEST)
Johan Cwiklinski <jcwiklin...@teclib.com> a écrit:
Hello all,
Hi
Hi
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
Not correct for plugin based on associated items of a ticket, because
the framework of GLPI change in 0.85.3
So i have plugin compatible >= 0.85 and <0.85.3 and >=0.85.3 and 0.90
(like webservices)
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.
In major version you can't change framework of GLPI, for plugin
compatibility
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
You have one manager by plugin, so it's difficult to do.
If you want to change the attachment of a plugin with glpi you must give
a very explain guidelines.
If not, user will not reverse there plugins to the community, that it's
not good...
Regards,
Nelly
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 ;)
David
++
Any thoughts?
++
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
