cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject RE: Proposal: release management guide (was Re: [RT] Versions)
Date Tue, 20 Apr 2004 14:20:32 GMT
First, I love the link that Marc posted.  That is exactly what Cocoon needs
- a page on the web site stating what contract the Cocoon project has with
its users.  It doesn't matter too much what that contract is, as long as it
is followed and provides a reasonable level of support.

In discussing the matter at hand, the first question I thought of was -
"When were the classes first deprecated?"  If it was 2.0, I believe that is
reasonable to remove them in 2.2.  If it was 2.1.0, then I would wait for
2.3. As you can tell, I don't completely agree with APR's contract (although
it is pretty good). Using MAJOR.MINOR.PATCH numbering, I don't believe
classes deprecated in a minor release should be removed in that release. My
feeling is that one minor release must always intervene before deprecated
classes are removed.

I know this is a pain for the development team - I've had to do exactly this
for years for my employers.

However, whether what I am recommending is what is accepted or not, I feel
it is imperative that a page similar to APR's be placed on the web site and
that it is followed.


-----Original Message-----
From: Carsten Ziegeler [] 
Sent: Tuesday, April 20, 2004 6:54 AM
Subject: RE: Proposal: release management guide (was Re: [RT] Versions)
> I currently don't think we have a release scheme that 
> supports one or the other: i.e. reality seems pretty much 
> like what Carsten is saying: 
> we just have 1,2,... 1004 (based on some gut feeling we seem 
> to be distributing those numbers over tripplets)
Yes, I think this is really the truth. And in reality things
get very complicated as compatibility for Cocoon as a whole
applies not only to what we develop but to most other projects
we incorporate. 
We are - for example - very eager in updating to new releases
of external libraries. So it happens, that we change from 
Xalan 2.4 to Xalan 2.6 between 2.1.3 and 2.1.4. (just a fictional
sample). It's a major change for Xalan, so it's not required
to be compatible. But if Cocoon or a users application relies
on some things that have changed between 2.4 and 2.6, then
Cocoon isn't compatible between 2.1.3 and 2.1.4 for them. And
of course, they blame Cocoon (which isn't soo wrong).

And in fact, these updates to the external libraries cause a
lot of problems to users when they try to update from one
version to another of Cocoon.

So, what do we do with all these infos?


View raw message