cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject RE: Continue Development of 2.1.x
Date Sun, 18 Apr 2004 16:32:50 GMT
Gosh, I wish I could use a real mail program. I've cut your message to just
the stuff I'm responding to.

1. I don't understand why you need separate repositories.  Why are CVS
branches not good enough?  On an unrelated topic, I would suggest looking at
subversion. I had to use if to grab something from the incubator and its
pretty cool. Plus it easily went through my companies firewall as it is http

2. Yes, we have to compile now. But that doesn't eliminate the binary
compatibility issues, it just reduces them.  In fact, I was using the APIs
you want to eliminate up until a few months ago when you posted the "proper"
way to get what I wanted.  The bottom line here is that once an API is
public you cannot know that it isn't being called by a user, unless it has
requirements that just can't be met in a "user component" (whatever that

3. The issues you raise regarding not being able to maintain binary
compatibility are one of my greatest concerns with using Cocoon and open
source in general. Once a formal release is made the project should be
rather draconian in its view of dependencies - they shouldn't be updated
unless they ONLY contain bug fixes. IMO product stability should be the
number one goal of point releases (i.e. 2.1.x), and it should improve with
each one.

However, I am not a Cocoon committer, so it really isn't up to me to say how
the respository is organized.  But as a user of Cocoon I care greatly about
how I am going to be able to maintain it after my system goes live.  I'd
prefer not to have to freeze it at a particular point release and perform
hand patches after that.


-----Original Message-----
From: Carsten Ziegeler [] 
Sent: Sunday, April 18, 2004 2:30 AM
Subject: RE: Continue Development of 2.1.x

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

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



View raw message