Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4082B759.1000202@apache.org>
Date: Sun, 18 Apr 2004 19:14:01 +0200
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Continue Development of 2.1.x
References: <OF6101B328.4102BECC-ONC1256E7A.00335BEE@sundn.de>
In-Reply-To: <OF6101B328.4102BECC-ONC1256E7A.00335BEE@sundn.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:

>Ralph Goers wrote: 
>  
>
>>It is highly unlikely that the project I am working on will 
>>use 2.2 as we have to be in production early next year and a 
>>significant amount of work has already been done.
>>
>>I am very much in favor of continuing to add new features to 
>>2.1 (such as the patch I just submitted), especially when 
>>they are completely binary compatible.  I believe 2.1 has a 
>>long life ahead of it.
>>
>>Frankly, I'd prefer that the current 2.2 become 3.0 and the 
>>incompatible changes go into a new 2.2.  It is my impression 
>>that what is now in 2.2 is going to end up being quite 
>>different from 2.1 and that it should not just be a point 
>>release.  
>>    
>>
>Yes, this is true for blocks.
>
>  
>
>>This would allow me to migrate to stay on 2.1 and 
>>maintain binary compatibility, move to 2.2 at the risk of 
>>minor incompatibilities, or move up to 3.0 where major 
>>differences happen.  I realize there is a risk with this, as 
>>nobody really likes to maintain two releases at one time, so 
>>2.1 is likely to stagnate.
>>
>>    
>>
>Yes, and we would have to need some restructuring of the cvs
>as it wouldn't make much sense to have our current "blocks" in
>the 2.1 repository while having 2.1, 2.2 and 3.0 repositories.
>Ah, and we still have of course the 2.0 one :)
>
>Now, I totally understand the binary compatibility reason, but
>if this is the only reason for having three repos (2.1, 2.2 and
>3.0), than I'm against it.
>  
>

+1

>We don't have binary releases, so if you update to a new Cocoon
>version, you have to compile at least Cocoon anyway. In 
>addition, you can never really be sure, that two 2.1.x versions
>are really binary compatible. We have too many dependencies to
>other projects that might have changed and sometimes we change
>something in an incompatible way without realizing it (this
>is very rarely but it happens). So, at least recompiling
>your own java code is imho strongly suggested (and you can
>use a never java compiler etc.)
>  
>

I think so too. If I upgrade Cocoon I *always* recompile my own Java 
classes. So I have never had any problem.

>As I said, the incompatibilities I mentioned is a) only in the
>Java source code, nothing else is affected, and even these changes
>are internal ones, so noone should suffer from them. 
>And of course, we document the incompatible changes clearly, so
>even if you are affected, you will know what you have to change.
>
>So in the end, I really would only have one repository for 2.1.x
>and one for the new blocks system (which is the current 2.2).
>  
>

+1

I think we should keep the blocks in the 2.1 repository because if we 
follow Ralph's proposal we would end in a separate blocks repository. 
And as soon as the _new_ blocks infrastructure is set up we will have to 
create another blocks repository and we end in 6 repositories:

 - 2.0
 - 2.1
 - 2.2
 - 2.x blocks
 - 3.0
 - 3.x blocks

In order to keep it as simple as possible I'm -1 on this and +1 on 
Carsten's proposal.

-- 
Reinhard