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