Hi Stefan, > 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).
Right. For customers and community users it's simple: MPXY. The point was more from a developer's point of view. > 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.. How would you do it is it's in a separate repository? As I see it the problem is similar with both approaches. Example problem: In 3.0MP5 (rev 12002) we released APRM 3.1.2. Now we're on changeset 12100 in the repo, APRM has been heavily modified. And we want to release a bugfix of APRM for MP5. With separate repos: Take 3.0MP5, your APRM repo, create a temporary head in the APRM repo, fix the issue. Merge the head. Package and release the new module. With multiple repos: Create a temporary head in the global repo, fix the issue. Merge the head, package and release a new module. As I see it the challenges and problems are similar in both cases. Do you foresee any other problems or difficulties? > 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? Fair enough. Modules should only be used when they add value. I cannot judge the existing ones in the 3.0 distribution, but this is a question we should always make in my opinion. > > . 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.. What I meant is that you can "hg up 3.0MPXY", fix the issue in the module and release a new version. So the info is kept in Mercurial so that you can get it easily, instead of querying CR or 15 repositories. > > - 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.... Maybe I've explained it incorrectly: imagine we want regular users to continue using APRM, the once shipped in 3.0 by default. But we want some early adopters to test and use a new major APRM version. We don't want everyone to change to that new APRM, but in an optional manner. Just an hypothesis. Thanks, Juan Pablo ------------------------------------------------------------------------------ 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
