|
Hello Nicolas and Jacques,
I will answer both your questions / comments here since they are related. This is my proposition for how the plugin mechanism works (nothing concrete yet, just ideas):
-
All OFBiz future releases would have equivalent plugin releases. So for example, if we have say .. release 18.04, we can have a plugin with the same version that is guaranteed to be compatible. You download the plugin using the ./gradlew pullPlugin, and NOT the ./gradlew pullPluginSource
-
OFBiz trunk, on the other hand, is not a released code. So, in order to install and test plugins for Trunk, you use the ./gradlew pullPluginSource
So published plugins exist only for releases (NOT for trunk). In my opinion this would greatly simplify the release process and it would give us independence from the underlying source code revision system.
In other words, it does not make a lot of sense to go down to revision-by-revision tracking of what works with that, that's just too much work. Instead, it's much easier to just have releases (with matching numbers) between released framework and plugins, and to have source-code to source-code compatibility between the ofbiz source code and the plugins source code.
So the next question is, how do we make sure that trunk always works with plugins? Well, the simplest answer that I can come up with is automated builds. We can have one buildbot script for OFBiz, and another buildbot script for Plugins. This way we can always catch problems while maintaining separate repositories.
So these are my thoughts, you're welcome to modify or start discussing on ML for more
|
Locked
