cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Continue Development of 2.1.x
Date Sun, 18 Apr 2004 17:14:01 GMT
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 
>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.


>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).


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.


View raw message