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. Ralph -----Original Message----- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 6:54 AM To: [EMAIL PROTECTED] 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? Carsten
