Le Tue, 20 Sep 2016 17:02:56 +0200 (CEST) Johan Cwiklinski <jcwiklin...@teclib.com> 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
