Hey,
On 2010-05-17, at 5:43 AM, Manik Surtani wrote:
>
> Backward compatibility
>
> Maintain minor version configuration file backward compatibility. We have to process
any previous version configuration file from the same minor version. For example,
Infinispan release 4.2 should process configuration file produced for version 4.1 without
any configuration file changes or any other adjustments. For configuration options present
in 4.2, but not in 4.1 assume default values. However, Infinispan version 5.0 is not
required to process configuration files from previous major versions, i.e 4.0...4.x.
I think we should still support this. (5.0 processing 4.x config files)
I'd say yes, unless the cost is prohibitively expensive in terms of hours needed to
develop support for such backward compatibility (here we would definitely need xyz40,
xyz50 beans), code maintenance, support for HTML configuration reference creation, testing
etc etc. If you do not mind I'd like to push this to 5.0 if we decide such a feature
is a must.
> Forward compatibility
>
> Not supported. We do not process any forward version configuration file. For example,
Infinispan release 4.1, given configuration file input from any succeeding versions (i.e
4.2...4.x, 5.x) would simply fail outright with proper error message.
Yes.
> However, that said, even forward compatibility could be supported to an extent - as
long as properties and elements from forward versions are not used in configuration file.
As soon as at least one element or a property from a forward version file is used - xml
schema validation will fail. If schema validation is turned off configuration file can be
processed.
Hmm... I suppose...
> Now, if you agree with these requirements we are already good to go! We are allowed
to introduce additional elements and attributes between minor version. We cannot remove
existing elements and attributes. Finally, there can not be any structural changes in
terms of already existing elements. For example, we can not reparent existing element to
another node, i.e say locking element instead of being a child of <default> or
<namedCache> suddenly becomes a child of transaction element.
Yes, makes sense.
I'll add a paragraph to XML configuration dev wiki to make sure no one breaks these
guidelines.