Stefan, Can you explain how do you imagine a Pi to Main pipeline promotion by having all the modules as separated hg repositories? I think that will help us to get your point.
Regards, PL On 02/12/2010 12:03, Stefan Huehner wrote: > On 12/02/2010 11:53 AM, Juan Pablo Aroztegi wrote: > > Some small first notes inside to get the discussion started. Can't yet > say which option i would prefer... > >> 2) As 3.0 is a distribution of modules, take those 15 modules and add them >> into the pi/main repositories, inside the modules directory. >> >> * Pros: >> . Creating a 3.0 development environment means cloning pi. And >> maintaining it means updating 1 repository. Similar to our current >> 2.50 approach. >> >> . Reproducing someone's environment is simple: there's only 1 >> revision ID. >> - Issue tracker: >> >> . It's easy to faithfully report an issue because there's only 1 >> revision > Most customer issues will probably (as in 2.50) reported against a > 'openbravo version' i.e. MPx so easier... so no revision id even known > to them as normally probably installed via CR and not hg (so back to one > core version + 16module versions). > > Related question: > what if we need to do an urgent update of for example myOB. Update all > 16 modules? or just this one module? If just one module our one version > scheme falls a bit apart or is at least inconsistent.. > > Just a 'bad idea' (tm): > If we do that and assume we don't want out of schedule updates of those > modules... Why are they modules at all? > Why not merge them into core and they are not modules at all anymore? > >> - Packaging: >> >> . No need to externally keep track of what modules match with that >> Core version. > Still need to if we have single module urgent updates out of the normal > MP cycle. And if we don't we don't use the 'offer' by modularity to only > update one module.. > >> - If we want to develop a new major version of a module included in the >> 3.0 distribution, then we'd need to create a separate repository for >> that module. > Why? If the next lets say myOB again has a new major version for the > next 3.0 MP then it could be changed inline (in sync with the deps from > other modules).. > Note at least until 3.0 this is quite common at least for the platform > modules.... > > Stefan > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Openbravo-development mailing list > Openbravo-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbravo-development ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Openbravo-development mailing list Openbravo-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbravo-development
