Ralph Goers wrote: > > 1. I don't understand why you need separate repositories. > Why are CVS branches not good enough? Yes, we discussed this some time ago and there were many reasons that a new repository is better and that it makes migration to subversion easier (at least I think this was one reason, I might be wrong). Anyways, from the maintenance POV, it's not really different if you have to maintain three branches or three repositories without branches.
> 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. Yes, and some ASF projects have already moved/are moving to subversion. Sooner or later all projects will move; but even if we would use subversion I think there is no difference as you still have to maintain the three different versions. If anyone wants to discuss the use of subversion for Cocoon, please don't do it in this thread and start a new one (This is not targetted at you, Ralph.) > > 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). Yes, unfortunately this is true. Now, we try to document that a user is using "not supported" API in the Java code, so it's the risk of the user to use it :) But as always, it might not be documented very well in all places. > > 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. Oh, this is not only a concern of Cocoon or Open Source in general. If you are using commercial frameworks, they sometimes change even due to a bug fix and "No, I'm not refering to MS here", this happened even with Apple (or more precisly with Next). > 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. Yes, I absolutely agree here in general...but :) I think it's ok to change the private API and in rare cases it's ok to change public API that does only affect very few users if any. But the later one of course only if it's well documented and there is a new way of doing the old things. > > However, I am not a Cocoon committer, so it really isn't up > to me to say how the respository is organized. But you belong to the Cocoon community and we really value everyone's opinion. It doesn't mean that a committer is always right. So, please keep on posting your comments and suggestions. Really appreciated. > 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. > Yes, I totally understand that and as I said, in general I agree but the changes I mentioned should really be harmless. Remember, that most of us committers are users, too. E.g. we (s&n, my employer :) ) are using Cocoon in many projects ranging from small to very big installations and we don't want to change our applications just because we are upgrading from let's say 2.1.4 to 2.1.5. So, in the end, I think, yes, all 2.1.x versions should in general be compatible but there should be (as always) exceptions to this rule. Carsten
