You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Bruce Schuchardt <bs...@pivotal.io> on 2017/05/03 18:12:57 UTC
can cache-1.0.xsd be modified?
We have a pull request that includes a change to cache-1.0.xsd. It
seems like that shouldn't be allowed and a new version of the xsd should
be created.
https://github.com/apache/geode/pull/474/files
Re: can cache-1.0.xsd be modified?
Posted by Jacob Barrett <jb...@pivotal.io>.
The version number should match the version of the product at least up into the minor point. If you're adding new features you should be rolling in minor point of the product version number anyway. So if the feature is a 1.1 feature you don't want to put it on the 1.0 schema because of somebody was using 1.0 of the product this feature wouldn't work if enabled or configured the XML config.
Sent from my iPhone
> On May 3, 2017, at 11:49 AM, John Blum <jb...@pivotal.io> wrote:
>
> I should clarify, if a feature is big enough, or there are many new
> additions, then I might bump the version and include the changes in the
> next release. However, to be clear, I don't think this is one of those
> changes.
>
> Additionally, I handle schema (XSD) versioning a little bit differently in
> SDG. That is, I actually bump the version of the XSD with every version
> change of SDG regardless of whether changes are actually made to the
> schema(s). But then, in *Spring*, users have the ability to specify a
> schema in an, unqualified, un-versioned manner, such as...
>
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:gfe="http://www.springframework.org/schema/gemfire"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/gemfire
> http://www.springframework.org/schema/gemfire/spring-gemfire.xsd
> ">
>
> Rather than...
>
> <beans xmlns="http://www.springframework.org/schema/beans"
> xmlns:gfe="http://www.springframework.org/schema/gemfire"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://www.springframework.org/schema/gemfire
> http://www.springframework.org/schema/gemfire/*spring-gemfire-1.9.xsd*
> ">
>
> This allows the developer to always use the latest, most up-to-date version
> of the XSD without making changes to their application, unless it causes
> them issues, then they can are free to declare a specific version as
> needed. This is accomplished by this file
> <https://github.com/spring-projects/spring-data-gemfire/blob/1.9.3.RELEASE/src/main/resources/META-INF/spring.schemas#L11>
> [1] that
> the core *Spring* container uses to resolve the URIs referencing the XSDs,
> including the unqualified (un-versioned) XSD.
>
> This might be worthwhile for Apache Geode to do as it saves the user a lot
> of headaches when upgrading.
>
> [1]
> https://github.com/spring-projects/spring-data-gemfire/blob/1.9.3.RELEASE/src/main/resources/META-INF/spring.schemas#L11
>
>
>> On Wed, May 3, 2017 at 11:31 AM, John Blum <jb...@pivotal.io> wrote:
>>
>> Hi Bruce-
>>
>> The general rule of thumb I use in SDG is that an XSD may be changed iff
>> it is only introducing something new and non-required.
>>
>> For example, a new element to add configuration support via XML that did
>> not exist before, but is not required (e.g. configuring the snapshot
>> service).
>>
>> Another example might be adding an attribute to an existing element where
>> again, the attribute is not required (i.e. optional), or provides a default
>> value.
>>
>> Adding required elements/attributes, removing existing elements/attributes
>> or changing types is a breaking change and will affect existing users XML
>> document instances based on that XSD version, in which case, you will need
>> to roll the version with a new XSD (e.g. cache-1.1.xsd or cache-2.0.xsd).
>>
>> Just glancing at this PR...
>>
>> <xsd:attribute name="socket-connect-timeout" type="xsd:string" use="
>> optional" />
>>
>> If that was the only schema change, then it should not cause an issue for
>> existing XML documents based on cache-1.0.xsd. The "use" is "optional".
>>
>> Hope this helps.
>>
>> -John
>>
>>
>> On Wed, May 3, 2017 at 11:12 AM, Bruce Schuchardt <bs...@pivotal.io>
>> wrote:
>>
>>> We have a pull request that includes a change to cache-1.0.xsd. It seems
>>> like that shouldn't be allowed and a new version of the xsd should be
>>> created.
>>>
>>> https://github.com/apache/geode/pull/474/files
>>>
>>
>>
>>
>> --
>> -John
>> john.blum10101 (skype)
>>
>
>
>
> --
> -John
> john.blum10101 (skype)
Re: can cache-1.0.xsd be modified?
Posted by John Blum <jb...@pivotal.io>.
I should clarify, if a feature is big enough, or there are many new
additions, then I might bump the version and include the changes in the
next release. However, to be clear, I don't think this is one of those
changes.
Additionally, I handle schema (XSD) versioning a little bit differently in
SDG. That is, I actually bump the version of the XSD with every version
change of SDG regardless of whether changes are actually made to the
schema(s). But then, in *Spring*, users have the ability to specify a
schema in an, unqualified, un-versioned manner, such as...
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="http://www.springframework.org/schema/gemfire"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/gemfire
http://www.springframework.org/schema/gemfire/spring-gemfire.xsd
">
Rather than...
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="http://www.springframework.org/schema/gemfire"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/gemfire
http://www.springframework.org/schema/gemfire/*spring-gemfire-1.9.xsd*
">
This allows the developer to always use the latest, most up-to-date version
of the XSD without making changes to their application, unless it causes
them issues, then they can are free to declare a specific version as
needed. This is accomplished by this file
<https://github.com/spring-projects/spring-data-gemfire/blob/1.9.3.RELEASE/src/main/resources/META-INF/spring.schemas#L11>
[1] that
the core *Spring* container uses to resolve the URIs referencing the XSDs,
including the unqualified (un-versioned) XSD.
This might be worthwhile for Apache Geode to do as it saves the user a lot
of headaches when upgrading.
[1]
https://github.com/spring-projects/spring-data-gemfire/blob/1.9.3.RELEASE/src/main/resources/META-INF/spring.schemas#L11
On Wed, May 3, 2017 at 11:31 AM, John Blum <jb...@pivotal.io> wrote:
> Hi Bruce-
>
> The general rule of thumb I use in SDG is that an XSD may be changed iff
> it is only introducing something new and non-required.
>
> For example, a new element to add configuration support via XML that did
> not exist before, but is not required (e.g. configuring the snapshot
> service).
>
> Another example might be adding an attribute to an existing element where
> again, the attribute is not required (i.e. optional), or provides a default
> value.
>
> Adding required elements/attributes, removing existing elements/attributes
> or changing types is a breaking change and will affect existing users XML
> document instances based on that XSD version, in which case, you will need
> to roll the version with a new XSD (e.g. cache-1.1.xsd or cache-2.0.xsd).
>
> Just glancing at this PR...
>
> <xsd:attribute name="socket-connect-timeout" type="xsd:string" use="
> optional" />
>
> If that was the only schema change, then it should not cause an issue for
> existing XML documents based on cache-1.0.xsd. The "use" is "optional".
>
> Hope this helps.
>
> -John
>
>
> On Wed, May 3, 2017 at 11:12 AM, Bruce Schuchardt <bs...@pivotal.io>
> wrote:
>
>> We have a pull request that includes a change to cache-1.0.xsd. It seems
>> like that shouldn't be allowed and a new version of the xsd should be
>> created.
>>
>> https://github.com/apache/geode/pull/474/files
>>
>
>
>
> --
> -John
> john.blum10101 (skype)
>
--
-John
john.blum10101 (skype)
Re: can cache-1.0.xsd be modified?
Posted by John Blum <jb...@pivotal.io>.
Hi Bruce-
The general rule of thumb I use in SDG is that an XSD may be changed iff it
is only introducing something new and non-required.
For example, a new element to add configuration support via XML that did
not exist before, but is not required (e.g. configuring the snapshot
service).
Another example might be adding an attribute to an existing element where
again, the attribute is not required (i.e. optional), or provides a default
value.
Adding required elements/attributes, removing existing elements/attributes
or changing types is a breaking change and will affect existing users XML
document instances based on that XSD version, in which case, you will need
to roll the version with a new XSD (e.g. cache-1.1.xsd or cache-2.0.xsd).
Just glancing at this PR...
<xsd:attribute name="socket-connect-timeout" type="xsd:string" use="optional
" />
If that was the only schema change, then it should not cause an issue for
existing XML documents based on cache-1.0.xsd. The "use" is "optional".
Hope this helps.
-John
On Wed, May 3, 2017 at 11:12 AM, Bruce Schuchardt <bs...@pivotal.io>
wrote:
> We have a pull request that includes a change to cache-1.0.xsd. It seems
> like that shouldn't be allowed and a new version of the xsd should be
> created.
>
> https://github.com/apache/geode/pull/474/files
>
--
-John
john.blum10101 (skype)