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