On 01.07.2007 17:18, Grzegorz Kossakowski wrote:
I agree that renaming would involve too much tinkering but I don't get
XML catalog solution fully. Do you want to say that publishing schema is
useless because we should always use XML catalogs for receiving schemas?
No, they should be released and published - if it would only be for
documentation. I would only not care so much about the cases when people
retrieve the schema from remote, i.e. our web site. If they retrieve
it locally it should be clear whether a particular version of a schema
is released or not.
Spring handles it the same way [1]. They did not even increase the
version number on changes [2]. Important is probably the backwards
compatibility. In that particular case: An XML written against Spring
2.0.2's AOP schema works in 2.0.3 as well despite the additional
attribute. No idea yet when it is better to force the user to update
his references.
I really don't like such a solution. I really like to know that
something released as x.y.z is never going to change. Otherwise, whole
versioning seems vague for me.
You need to have the following in mind: Somebody wants to upgrade from
Cocoon 2.2.3 to 2.2.4. In that step to one of the schemas an additional
and optional attribute was added (like that case in Spring's AOP
schema). In theory the jars would be a drop-in replacement. With
increasing the version number of the schema you have to adapt all your
references to the new version just to get your app working again. Or
you'd need to hold all versions probably in use in your local XML
catalogue or access them remotely. Since Spring has the schemas on the
class path, they are just replaced with the jars. Despite the vagueness
nobody actually needs to care about the schema version. For that reason
I'd probably go with a constant number as long as it is backwards
compatible. And it should be for on particular minor level.
Joerg
