Sylvain Wallez wrote:
I don't clearly understand what you want to achieve...
It's plain simple :) Now, the usual way would be to create a new repository (cocoon-2.2) and copy everything from 2.1 in there. Then we have two "branches" which require syncing which can be a real pita. My approach is to sync as less as possible by only copying those parts that we will change in the near future. And this should be the core sources, but not the documentation or any block.
Ah, so we'll have a 2.2 repo containing only those parts whose structure will change, and keep the 2.1 repo as a "fallback" for those parts whose structure is the same (but who may have been upgraded since 2.1.0) ?
But how do we decide that some modifications should occur in 2.2 and not in 2.1 ?
As I expect that we will end in a different structure when we have real blocks (e.g. perhaps a blocks repository etc.) this would be imho an easier migration strategy.
That's right. With real blocks, we'll have several distinct CVS repositories. But will we have distinct "kernel" and "core component" blocks ? Should the kernel be really naked (in which case it may even contain only the block manager and the main interfaces but nothing else), or should it provide the common services used by every application (e.g. WildcardMatcher, FileGenerator, HTMLSerializer, etc) ?
Does this make sense?
Yep. But the granularity has to be found. Maybe we should wait for Stefano's RT so that everybody has a common understanding of the consequences of blocks on the Cocoon organisation.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
