Well, the way I handle this in *Spring Data for Apache Geode* is, and to *Kirk's* point, the schema (XSD) version matches the SDG version. I.e. in SDG 2.0.0 [1] there is a spring-geode-2.0.0.xsd, and in SDG 2.1.0 [2] there now exists a spring-geode-2.1.0.xsd.
So, you could have a cache-1.1.xsd, or a cache-1.6.xsd to match the next Apache Geode version. I suggest the later. If you parser is smart enough (which *Spring's* is), then you can also have something like this [3], which "defaults the version", when the user does not explicitly call out the version in an XML document instance based on the XSD. Food for thought, John [1] https://github.com/spring-projects/spring-data-geode/tree/2.0.6.RELEASE/src/main/resources/org/springframework/data/gemfire/config [2] https://github.com/spring-projects/spring-data-geode/tree/2.1.0.M2/src/main/resources/org/springframework/data/gemfire/config [3] https://github.com/spring-projects/spring-data-geode/blob/2.1.0.M2/src/main/resources/META-INF/spring.schemas On Tue, Apr 17, 2018 at 8:32 AM, Jinmei Liao <jil...@pivotal.io> wrote: > but our xsd is versioned. If user wants to use a more "correct" xsd when > they are creating a cache.xml file, should we allow them to reference a > cache-2.0.xsd instead of cache-1.0.xsd? (provided that 2.0 is only a washed > down version of 1.0, nothing new added). > > On Tue, Apr 17, 2018 at 8:28 AM, Michael Stolz <mst...@pivotal.io> wrote: > > > Correct. We can "deprecate" any time we like as long as we have provided > an > > alternative, but we should only "remove" on a major release. > > > > -- > > Mike Stolz > > Principal Engineer, GemFire Product Lead > > Mobile: +1-631-835-4771 > > Download the new GemFire book here. > > <https://content.pivotal.io/ebooks/scaling-data-services- > > with-pivotal-gemfire> > > > > On Tue, Apr 17, 2018 at 10:51 AM, Anthony Baker <aba...@pivotal.io> > wrote: > > > > > Deprecation is a signal that a user should begin migrating to an > > > alternative because that thing may be removed in a future release. > > > Following the SemVer practice gives our users confidence that we won’t > > > break stuff in a minor release. > > > > > > Anthony > > > > > > > > > > On Apr 16, 2018, at 3:11 PM, Kirk Lund <kl...@apache.org> wrote: > > > > > > > > We should probably target removal of the "deprecated" cache xsd > > > > types/elements in Geode 2.0. I'm not sure if we can introduce > > > cache-2.0.xsd > > > > before Geode 2.0 or not (anyone know?). > > > > > > > > On Mon, Apr 16, 2018 at 2:59 PM, Jinmei Liao <jil...@pivotal.io> > > wrote: > > > > > > > >> Simply searching "deprecated" in cache-1.0.xsd, we have 15 hits. > Would > > > it > > > >> make sense to start creating a cache-2.0.xsd? or better yet, a > > > >> server-cache-2.0.xsd and a client-cache-2.0.xsd? > > > >> > > > >> > > > >> On Mon, Apr 16, 2018 at 2:55 PM, Patrick Rhomberg < > > prhomb...@pivotal.io > > > > > > > >> wrote: > > > >> > > > >>> Some types / fields have their deprecation noted in their > > > documentation, > > > >>> within the <xsd:documentation> block. Alternatively / in addition, > > > some > > > >>> xsd:element have the block > > > >>> > > > >>> <xsd:annotation> > > > >>> <xsd:appinfo>deprecated</xsd:appinfo> > > > >>> </xsd:annotation> > > > >>> > > > >>> > > > >>> Although I don't know if these annotations count as "visible," but > > they > > > >> are > > > >>> there. > > > >>> > > > >>> On Mon, Apr 16, 2018 at 1:49 PM, Jinmei Liao <jil...@pivotal.io> > > > wrote: > > > >>> > > > >>>> I don't think we have a process for deprecating elements in > > cache.xml > > > >>>> yet.... All the changes we've had so far are additions, not > removal. > > > >>>> > > > >>>> The reason I am asking is that we are creating POJO's (started by > > JAXB > > > >>> tool > > > >>>> from xsd file) that would generate the cluster configuration xml > > > >>>> automatically. As long as we know there are "new" ways to do > things, > > > we > > > >>>> should have these POJO's only generate XML that's in the new > style. > > > >>>> > > > >>>> Thanks! > > > >>>> > > > >>>> On Mon, Apr 16, 2018 at 12:01 PM, Jason Huynh <jhu...@pivotal.io> > > > >> wrote: > > > >>>> > > > >>>>> Hi Jinmei, > > > >>>>> > > > >>>>> I am not sure whether these elements were deprecated or not. I > > know > > > >>> that > > > >>>>> they were at one time valid and a user could specify the > following > > in > > > >>>> their > > > >>>>> app at one point: > > > >>>>> > > > >>>>> <index name="pk1"> > > > >>>>> <primary-key field="ID"/> > > > >>>>> </index> > > > >>>>> > > > >>>>> I believe the "new" way to do this would be: > > > >>>>> > > > >>>>> <index name="pk1" type="key" from-clause="/region r" > > > >> expression="ID"/> > > > >>>>> > > > >>>>> How would deprecation for this work? Would your roll a new > version > > of > > > >>>>> the new definition/scheme? > > > >>>>> > > > >>>>> > > > >>>>> On Mon, Apr 16, 2018 at 10:28 AM Jinmei Liao <jil...@pivotal.io> > > > >>> wrote: > > > >>>>> > > > >>>>>> From the cache-1.0.xsd, we noticed that an index can have > element > > > >>> like > > > >>>>>> "functional" and "primary-key", but the docs did not mention > > > >> anything > > > >>>>> about > > > >>>>>> it ( > > > >>>>>> > > > >>>>>> https://geode.apache.org/docs/guide/13/reference/topics/ > > > >>>>> cache_xml.html#region > > > >>>>>> ). > > > >>>>>> I am wondering if these are deprecated? Would it be better for > the > > > >>> the > > > >>>>> xml > > > >>>>>> created by the cluster configuration not consist any of these? > > > >>>>>> > > > >>>>>> <xsd:choice minOccurs="0"> > > > >>>>>> <xsd:element name="functional"> > > > >>>>>> <xsd:annotation> > > > >>>>>> <xsd:documentation> > > > >>>>>> A functional type of index needs a from-clause, > expression > > > >>>>>> which are mandatory. > > > >>>>>> The import string is used for specifying the type of > Object > > > >>> in > > > >>>>>> the region or > > > >>>>>> the type of Object which the indexed expression evaluates > > > >> to. > > > >>>>>> </xsd:documentation> > > > >>>>>> </xsd:annotation> > > > >>>>>> <xsd:complexType> > > > >>>>>> <xsd:attribute name="expression" type="xsd:string" > > > >>> use="required" > > > >>>>> /> > > > >>>>>> <xsd:attribute name="from-clause" type="xsd:string" > > > >>>> use="required" > > > >>>>> /> > > > >>>>>> <xsd:attribute name="imports" type="xsd:string" > > > >> use="optional" > > > >>> /> > > > >>>>>> </xsd:complexType> > > > >>>>>> </xsd:element> > > > >>>>>> > > > >>>>>> <xsd:element name="primary-key"> > > > >>>>>> <xsd:annotation> > > > >>>>>> <xsd:documentation> > > > >>>>>> A primary-key type of index needs a field attribute which > > > >> is > > > >>>>>> mandatory. > > > >>>>>> There should be only one or zero primary-index defined > for > > > >> a > > > >>>>> region > > > >>>>>> </xsd:documentation> > > > >>>>>> </xsd:annotation> > > > >>>>>> <xsd:complexType> > > > >>>>>> <xsd:attribute name="field" type="xsd:string" > use="required" > > > >> /> > > > >>>>>> </xsd:complexType> > > > >>>>>> </xsd:element> > > > >>>>>> </xsd:choice> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> -- > > > >>>>>> Cheers > > > >>>>>> > > > >>>>>> Jinmei > > > >>>>>> > > > >>>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> -- > > > >>>> Cheers > > > >>>> > > > >>>> Jinmei > > > >>>> > > > >>> > > > >> > > > >> > > > >> > > > >> -- > > > >> Cheers > > > >> > > > >> Jinmei > > > >> > > > > > > > > > > > > -- > Cheers > > Jinmei > -- -John john.blum10101 (skype)
