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