If it is a big concern can't we mark our own classes/fields relying on Beta APIs as experimental and subject to change?
In [1] they also say the following about Beta APIs: "All this said, @Beta features tend to remain relatively stable. If we decide to delete a @Beta feature, we will typically deprecate it for one release before deleting it. On the other hand, if you want something taken out of @Beta, file an issue. We generally promote features out of @Beta only when it's specifically requested, so if you don't ask, it won't happen." So in the meantime let's also request them to promote the respective APIs from beta. Best, Stamatis [1] https://github.com/google/guava/wiki/PhilosophyExplained On Tue, Sep 29, 2020 at 9:31 PM Julian Hyde <[email protected]> wrote: > For the record, the Druid adapter has used RangeSet for a long while, and > it made sense, because Druid was doing tricky computations on date ranges. > Introducing Sargs brought that style to other parts of Calcite. > > If someone was to build an adapter similar to the Druid adapter, based on > 1.26, externally to Calcite, they probably would not have to depend on > RangeSet because Calcite’s Sarg class would do the rewrites that they need. > > Julian > > > > On Sep 29, 2020, at 12:24 PM, Vladimir Sitnikov < > [email protected]> wrote: > > > > Julian>The vast majority of clients who use Sarg (or expressions that > > contain Sarg) will not reference RangeSet > > Julian> directly and therefore would not be impacted. So I think it’s an > > acceptable risk. > > > > Well, it is hard to tell, however, I know Druid is using Sargs, and, I > > guess, Druid is one among the very least tested adapters. > > See > > > https://github.com/apache/calcite/pull/2182/commits/edf57dce13d00d3f7c4035c323f5de2568dc8699 > > > > In other words, Druid adapter proves Calcite forces clients to use > > Guava's @Beta API :( > > > > Vladimir > >
