Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F3A4D30.9060209@anyware-tech.com>
Date: Wed, 13 Aug 2003 16:37:36 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Starting 2.2
References: <LKENJPKDAIKAPKHEOCMMAEKJEKAA.cziegeler@s-und-n.de>
In-Reply-To: <LKENJPKDAIKAPKHEOCMMAEKJEKAA.cziegeler@s-und-n.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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