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 <bschucha...@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)
