Re: [Glpi-dev] Plugins versions and compatibility
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
Re: [Glpi-dev] Plugins versions and compatibility
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? 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 :) > > 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'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, -- Johan ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Plugins versions and compatibility
Le 21/09/2016 à 11:44, David DURIEUX a écrit : Le Tue, 20 Sep 2016 17:02:56 +0200 (CEST) Johan Cwiklinski 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
Re: [Glpi-dev] Plugins versions and compatibility
Le Tue, 20 Sep 2016 17:02:56 +0200 (CEST) Johan Cwiklinski a écrit: >Hello all, 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 >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 ;) David ++ >Any thoughts? > >++ ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev