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: http://apr.apache.org/versioning.html 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' compatibility
'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= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
