+1 about allowing experimental modules in trunk, BUT I think that we should evaluate each specific case and not abuse of it.
I want to avoid dead code in trunk (we have had many branches/sandbox that was simply experiments and not born to be included in trunk). Many times I think that branches will be needed because of changes in interfaces between modules. E.g: most of the current branches requires changes in the whole codebase and not limited to a single module. Furthermore I would like to see first the result of modularization: I think it is still incomplete as the "core" library is including a lot of stuff and I didn't get how to split them by using the "3-layers" limit you have with the ant build. Stefano robert burrell donkin ha scritto: > i would like to suggest that JAMES adopts a slightly different > approach to the development of extra and alternative functions. ATM we > use branches for experimentation but i think that these are several > disadvantages in this: > > * collaboration is more difficult > * hard to shared between branches > * more difficult to compare and contrast different approaches to > similar problems > * hard to take advantages of improvement in code made on the trunk > > with the new modular system i think that it should be possible to > develop addition and alternative functions in trunk by using > experimental modules. > > so, i would like to propose we allow experimental modules in trunk. > these will be prefixed 'experimental' and contain either alternative > implementations or new functions which are not yet mature enough to be > a full part of JAMES. these modules would not be included by default > in JAMES but would included as part of the unified build and could be > added in by altering the configuration. > > opinions? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
