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 <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)
