e broken backwards compatibility on one or two
> occasions, but I’ve never been affected by that personally.
>
>> On Sep 6, 2016, at 12:04 PM, Andrew Purtell <apurt...@apache.org> wrote:
>>
>> No argument that naming should set expectations of immutability if that's
>&
>> dependency (i.e. we call via reflection) and we can provide fallback
>> for older versions. All of this is identical to our policy for JDKs,
>> really.
>>
>> All we need is that our dependencies move off the really old versions
>> in a timely fashion.
>>
&
Use hbase-shaded-client as Maven dep (1.1 and up)
> On Sep 3, 2016, at 10:12 AM, James Taylor <jamestay...@apache.org> wrote:
>
> Does shading of protobuf on the HBase client work (or is that dependent on
> that brave work Stack is doing)?
>
> On Sat, Sep 3, 2016 at
g guava/protobuf.
>>
>> On Sat, Sep 3, 2016 at 9:48 AM, Andrew Purtell <andrew.purt...@gmail.com>
>> wrote:
>>
>>> Since Calcite should become a widely used library (smile) I think it
>> would
>>> be prudent to shade Guava and protobuf if C
the devil...
>
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/util/GuavaPatcher.java
>
> On Sat, Sep 3, 2016 at 8:16 AM, Andrew Purtell <andrew.purt...@gmail.com>
> wrote:
>
>> While that seems very unfriendly of them,
>>> the same). For that reason, we've made sure Phoenix can work with this
>>> version too. Phoenix may not need to depend on Calcite on the
>> server-side,
>>> and Phoenix and HBase both have shading, so there may be some avenues of
>>> escape.
>&g
