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
