All, here you are my comments on this hot topic.
From a strategic point of view: -First we have to clarify where are we going and then we will be able to define how to go there. From 3.0 the objective is to make Openbravo a packaged distribution of modules made by Openbravo and 3rd parties. This is one of the main benefits of opensource + modularity: third parties can collaborate with the project (even in the main distribution) in a decoupled manner. -The "decoupled manner" is key in the last statement: we can not couple our development process with the development process of 3rd party teams. We can not include 3rd party modules in our distribution if those are not fairly stable, complete and ready quite ahead of our packaging process (similar to 3rd party jar libraries). -Although we not have today 3rd party modules in our distribution (we are in the early stages of 3.0 release), we should be ready to manage them efficiently when they come. So, from a tactical point of view: -I'm fine with Juanpa's proposal (put all modules together in the same repo) provided that it does not limit our mid/long term objective of making Openbravo a distribution (I don't see this is the case). -Although all the modules are together in one repository, publishing in the Central Repository will happen one by one, only in case there have been changes in that particular module. So Hudson will check if the module has had changes since the last release, and only in case there has been at least one change promoted to main in that period it will create a new version (minor) of that module. -Sooner than later we will include other modules made by third parties. For those modules the approach will be completely different: we will work with them as static obx files (using their latest GA version). It will be managed in a very similar way to jar libraries (included in our repo, but not managed by it). -Gradually, as soon as our modules included in the distro mature and become stable (eg. after several MP's without publishing new version, and without planned changes on them), those modules might be moved out from the common code line to a specific repository and managed in the common repository as if they were third party modules. In that moment the module will start a different life cycle, and won't be automatically published by our release process but in an ad-hoc manner. -Coming back to a monolitic distribution (merging the code of the modules within the code of core) is out of discussion. There is no benefit on it (more than reducing the complexity of managing dependencies) and it would ruin all the effort we have done to split our product into parts. It is true that we have not been able yet to do a complete and clean split of core but still we have already removed a big part of the Application Dictionary and the financial flows. We should keep taking bites out of it (projects, manufacturing, crm, etc.) so one day it will be light enough to be completely replaced. I only see two tactical problem's and no strategic problems/limitations with Juanpa's approach: 1.-The structure of one repository for several modules sounds fuzzy and might lead to confusion 2.-We will split the history of changes in our modules to different periods since we have problems to move the changesets from one repository to the other (due to both use different sourcepaths). The first problem can be solved with very good documentation that Release Management will prepare :-) Any idea to solve the second problem? Ismael -----Mensaje original----- De: Pablo Luján [mailto:pablo.lu...@openbravo.com] Enviado el: martes, 07 de diciembre de 2010 17:06 Para: Iván Perdomo CC: openbravo-development@lists.sourceforge.net Asunto: Re: [Openbravo-development] New proposal for the 3.0 code split Iván, As far as I see, the main issue with having all the modules bundled in a single branch is about how the updates will be managed. If I got a fix for module X, I do not want to download module X + core + all the 14 modules. I want only module X with my fix. Furthermore, I might want to keep X module in a different maturity level than the rest of modules. Having separated code lines is more flexible from the user perspective. The main issue I see with this approach is how to get an stable environment, for example, for deciding if a PI revision is stable enough to be promoted to Main. Regards, PL On 07/12/2010 16:50, Iván Perdomo wrote: > Hi all, > > On Thu, 2 Dec 2010 11:53:00 +0100 > Juan Pablo Aroztegi<juanpablo.arozt...@openbravo.com> wrote: > >> Core is not of use by itself, it needs other modules to >> work. > If Core is not of use by itself, why we don't make useful? > > To me is clear that if Core can't work without these 'base' modules, > this ones are part of Core. We don't need to have a different code > repository for them, nor having them under the modules folder. These > 3.0 base modules should be part of 'src'. > > If we start doing things like, defining dependencies of Core on other > modules we are breaking the rule of 'Core' _is the base module_ and > the starting point of the rest. I know that we support this type of > dependencies but, to me, makes no sense. > > My proposal: > > * Place all the code from the 'new architecture' modules (weld, kernel, > smartclient, client.application, etc) into Core, and leave the module > repositories for bugfixing and supporting 2.50. Remember that we > support the 'New Selectors' in 2.50, and these module use this new > architecture. > > With this approach we follow the same defect/backport strategy. If we > need to fix a defect, we solve it in 3.0 code line, and then (if > necessary) backport the change to the specific module repository. > > * Core 3.0 'merges' all this modules. When upgrading a 2.50 instance > to 3.0 all the required stack is part of core, so the modules will > get deleted. > > > Let me know what do you think? > ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Openbravo-development mailing list Openbravo-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbravo-development ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ Openbravo-development mailing list Openbravo-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbravo-development
