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.Yes, this is true for blocks.
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.
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
