cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Proposal: release management guide (was Re: [RT] Versions)
Date Tue, 20 Apr 2004 13:17:32 GMT

Carsten Ziegeler wrote:
> Marc Portier wrote:

>>in general I'm all for a more formal description of the 
>>meaning of versions to us.
>>something like: but 
>>probably more focussed towards Java classes, interfaces, xml 
>>schema's and namespaces ?
>>from there we could probably formulate some guidelines 
>>towards associating code maintenance actions like
>>- bugfixing
>>- deprectation
>>- addition
>>- removal
>>and how that is reflected in our cvs management towards
>>- tagging
>>- branching/merging
>>- new repository
> Yes, good idea!
> Do I understand you correctly that you are volunteering? Great :)

not really: I was hoping somebody was going to direct me to the URL of 
the existing ones that could end my confusion :-)

in any case I'm not too shy to start this thread, and see where a joint 
effort can bring us, I'm not the guy that wants everything carved in 
stone, on the other hand it seems such a waste of time to discuss and 
re-evaluate this kind of stuff on a case per case...

here goes:
I see some difference between what I would call 'extension' vs. 'usage' 

'usage' compatibility would be the guarantee that my xml files (elements 
and namespace declarations) keep on being picked up by the machinery and 
dealth with correctly (sitemap semantics, generator/transformer-picked 
up elements, config file entries...)

it seems logic that this can grow, but should however remain backwards 
compatible over the various minor releases of the same major release

parts of this usage we want to deprecate could be flagged through 
run-time warnings to logger.warn() but remain supported (this would 
indicate that an upcoming major release will no longer support this)

'extension' compatibility would be the guarantee that my own extensions 
to what cocoon provides (own java classes that interface directly with 
protected/package/public members in our distribution, and maybe also my 
own javascript code that depends on cocoon provided library-functions)

maintaining these over various minor releases seems more then we need, 
so keeping these stable within the scope of one minor release (ie across 
the various patch-releases) should do.  This would mean that parts of 
that intreface can get deprecated but no additions/removals could happen.

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)

comments welcome,

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message