cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Continue Development of 2.1.x
Date Sun, 18 Apr 2004 17:31:59 GMT
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


Mime
View raw message