Hi Johan,
Le 28/09/2016 à 17:04, Johan Cwiklinski a écrit :
Hello,
Thanks for you comments :)
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)
Well, for plugins Nelly talks about, it is a nonsense to have a GLPi version in
their own versions.
For fusioninventory.... Well, it is generally compatible with one major version
of GLPi, so it makes sense.
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
You mean minor, right?
yes minor. For major you change API
Anyways, I totally agree, plugins must not be broken between versions as far as
possible (even in major), but we cannot ensure we won't break anything with
minor changes on core's code :-/
What I had in mind is: what if we have to change something, say for security
reasons, that will break plugins? Well, that should not be something we'll see
each day :)
Leader of plugin knows that database can change between major version.
So, for me, in minor version you don't add new functionalities but only
bug correction
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...
The point is to get a maximum of chances not to break plugins without plugins
can know, and prevent to upgrade plugins when it is not really needed (most of
the cases I've seen for the 9.1 upgrade so far).
I do not thing adding one or two lines of code will prevent contributions from
the user; that is not a complete rewrite of the whoe system ;)
Except for the min/max version, what would really affect plugins development;
what I propose is too find some guidelines and to document them; that last part
is very important; I'm not talking about rules everyone have to follow :)
In those guidelines, there will be some parts that are required (like adding some
functions in the setup.php) and some other that will be completely "good
practices"; up to the user/developer to do what he wants.
I'll have to work on some plugins; and I'll probably have to follow some
guidelines, so I can't get lost. I'd prefer to work on global guidelines than
editing a txt document on my part ;)
Ho, also... I've seen a plugin that declares a constant for its version, making
it quite easy to retrieve (let's say, for packaging for example?). So I also
propose (as a guideline!) to set a {PLUGINNAME}_VERSION constant.
I use this on some of my plugin: it's for compatibility between 2 plugins
Yllen
I've begin to work on a developer documentation today; I had in mind to add a
plugins part on it to resume my proposals. If that is ok for you all, I'll work
a bit on it, and submit you the result before it's published.
Good evening,
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
