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
