cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Starting 2.2
Date Wed, 13 Aug 2003 14:37:36 GMT
Carsten Ziegeler wrote:

>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



Mime
View raw message