Hi, As far as I've understood, the plan going forward is to have separate release cycles for all Sling components. Does this mean that each component would get their own trunk,branches,tags structure, or do we still keep everything inside a single trunk and perhaps use subdirectories within the existing branches and tags directories?
How will inter-component dependencies be managed? Currently many components in the trunk depend on the released 2.0.2 versions, so you end up with a bit confusing setup where the build generates one version of one component but downloads another version as a dependency for another component. Perhaps that's just OK. Do we have the release management capacity to manage dozens of separate release cycles? I mean, even if we did just a single release per year for a component, we'd still be releasing stuff almost weekly. To simplify things, would it make sense to make the components more coarse-grained? For example, would it be bad to merge all the commons components into a single utility component? Also, do all the components need to be bundles or would it make more sense for them to be normal jars that bundles that require that functionality just embed? The way I see it (and I may well be wrong) is for bundles to be used for coarse grained and loosely coupled services. I for example don't see why the commons/json component should be a separate bundle and not an internal dependency of whatever bundle that requires JSON functionality. BR, Jukka Zitting
