+1 I see no semantic difference between adding a new method vs implementing a stub that previously threw UnsupportedOperationException
> On May 23, 2019, at 12:56 PM, Udo Kohlmeyer <u...@apache.org> wrote: > > +1 to implementing this method. > > There is no plausible reason NOT to implement this. > > --Udo > > On 5/23/19 12:44, Dan Smith wrote: >> +1 to implementing this method in a minor release. >> >> I'm with Jake on this one. Every bug we fix changes the behavior of the >> product in some small way. This seems like a behavior change for the better >> - I can't picture a use case where someone is actually *relying* on this >> method throwing UnsupportedOperationException. >> >> I suppose someone might write a test that this feature is not supported - >> but it seems like the only reason to do that would be to detect when geode >> starts supporting getStatistics, so they'd probably be happy to see >> getStatistics start working! >> >> >> -Dan >> >> On Thu, May 23, 2019 at 10:31 AM Anilkumar Gingade <aging...@pivotal.io> >> wrote: >> >>> I agree, this may not look like the usecase that one would be using or >>> depending. Going with the backward compatibility requirement this will be >>> breaking that contract. >>> Again, based on the scenario and usecases, there could be exceptions. I am >>> trying to see if the versioning support that's used to keep the backward >>> compatibility contract can be used here. >>> >>> On Thu, May 23, 2019 at 10:17 AM Jacob Barrett <jbarr...@pivotal.io> >>> wrote: >>> >>>> But what application is going to legitimately call this method and expect >>>> that it throw an exception? What would be the function of that usage? >>>> >>>> If you assume that calling this method under these conditions had no >>> value >>>> and would therefor never have been called then one could argue that >>>> implementing this method is adding a feature. It adds a case where one >>>> could legitimately call this method under new conditions. >>>> >>>>> On May 23, 2019, at 10:06 AM, Anilkumar Gingade <aging...@pivotal.io> >>>> wrote: >>>>> As this changes the behavior on the existing older application; it >>> seems >>>> to >>>>> break the backward compatibility requirements. >>>>> We use client versions to keep the contracts/behavior same for older >>>>> client; can we do the same here. >>>>> >>>>> -Anil. >>>>> >>>>> >>>>> On Thu, May 23, 2019 at 8:33 AM Darrel Schneider < >>> dschnei...@pivotal.io> >>>>> wrote: >>>>> >>>>>> Is it okay, in a minor release, to implement Region.getStatistics for >>>>>> partitioned regions? See GEODE-2685. The current behavior is for it to >>>>>> always throw UnsupportedOperationException. I doubt that any >>>> application is >>>>>> depending on that behavior but it could be. I know we have seen >>> changes >>>>>> like this in the past break the tests of other products that are >>>> layered on >>>>>> top of Geode. >>>>>> Should this type of change be considered one that breaks backwards >>>>>> compatibility? >>>>>> >>>>
