XSD versions have always matched the version of the GemFire release. Starting with Geode 1.0, the XSD version was matched up with Geode release. So, for example, if we need to introduce a new XSD in Geode 1.7, then it should be named geode-1.7.xsd.
On Tue, Apr 17, 2018 at 8:55 AM, John Blum <jb...@pivotal.io> wrote: > 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) >
