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 based. 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 is). 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. Ralph -----Original Message----- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Sunday, April 18, 2004 2:30 AM To: [EMAIL PROTECTED] 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). WDYT? Carsten
