Joerg Heinicke pisze: > 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.
Ok.
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.
I wonder what will be broken if someone sticks to 2.2.3 version of schema? He will not be able to use new attribute but what will be rally broken in that case?
-- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
