On 12/02/2010 12:53 PM, Juan Pablo Aroztegi wrote: > >> 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? The release part of some out-of-plan extra module version will i guess just work as you mentioned. But then after that how does a developer create a local workspace containing that mix? If he needs to work on top of that combination? I.e. how to get: - rev 12002 (mp5) for everything - rev 12100 just for modules/<aprm> ?
>> 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. Benefit of 'not' having the modules is no need do manage intra-dependencies on >=15 modules. But loosing the option to do 'out-of-plan' updates to a single module as outlined above. > >>> - 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. I guess we keep the 2.50 line (1.x) of aprm in a seperate repo as of now and for 3.0 would only support the bundled version. But creating another extra repo is possible if really needed. Stefan ------------------------------------------------------------------------------ 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
