I think starting any vote right now might be a little premature. I list below what I propose as the logical sequence of steps to take:
- Create a maven repo for OFBiz plugins - Update the plugins API to be able to pull and push to that repo - Allow contributors some time to get familiar, fix bugs, and improve the workflow for plugins - Separate the builds for the plugins from the builds for the framework and fix all dependency problems (from framework to plugins) - Start a thread to discuss the release strategy once all the technical issues of the plugin system are completed. This would include things like versioning the plugins, releasing them, where to place them on the website, how to update them, etc. This is a rather complex topic that requires further discussion. For example, we release all plugins but the plugin system allows installing individual plugins. So we might need two releases, one for all plugins in a compressed archive, and another one in the maven repository. So I would suggest not to rush this before we test and fully understand how the plugin system will work which is going to enforce how we can do things anyway. Cheers, Taher Alkhateeb On Wed, Apr 12, 2017 at 9:42 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Mmm, I realise my last message is ambiguous. > > I mean, should I start a vote? > > Without any answers I'll assume it's a lazy consensus > > Thanks > > Jacques > > > > Le 12/04/2017 à 08:24, Jacques Le Roux a écrit : > >> Hi, >> >> Without any reactions, and because I believe this is important I'll start >> a vote >> >> If I get no attention at all, I'll consider this is a lazy consensus and >> will enforce this rule in the committers page in wiki >> >> Thanks >> >> Jacques >> >> >> Le 14/03/2017 à 08:25, Jacques Le Roux a écrit : >> >>> To sum up and as a kind of TL;DR, the question is <<should we "force" >>> the committers to maintain the plugins?>> >>> >>> Jacques >>> >>> >>> Le 14/03/2017 à 08:17, Jacques Le Roux a écrit : >>> >>>> Hi, >>>> >>>> In recent discussions I wrote >>>> >>>> <<I believe committers need now to agree about checking out all plugins >>>> and maintaining them as we did before. This must be documented in our >>>> policies.>> in <<[DISCUSSION] Plugins: svn:external or Gradle Task?)>> >>>> thread >>>> >>>> <<It seems to me that if a committer, committing something on the >>>> framework, breaks a plugins s/he is also responsible of fixing the plugins >>>> issue.>> in <<[proposal] actions to take with plugins>> thread >>>> >>>> but got no attention so far. >>>> >>>> Beside the last pending technical aspects defined in the <<[DISCUSSION] >>>> Proposed Task List for Moving Forward with Gradle and the Trunk>> >>>> http://markmail.org/message/6r4qnuu5v2c2aes2 >>>> >>>> 6. Investigate how to create a plugin repository with dependencies >>>> clearly defined, not only on external libraries but also other plugins! >>>> 7. Investigate and propose a methodology for maintaining plugins and >>>> versioning compatibility with OFBiz. >>>> 8. Investigate and propose a methodology for upgrading plugins within >>>> OFBiz >>>> >>>> I think we need to agree, not at a technical but political level, about >>>> how the plugins will be maintained, IMO not as second-class citizens! >>>> This is a very important topic because with the trunk split it's >>>> already there and the plugins could suffer from the split. >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >>>> >>>> >>> >>> >> >> >
