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/
mpo@outerthought.org mpo@apache.org
|