On 10/15/18 12:25 PM, Julian Hyde wrote:
What if we switch things around: instead of depending on the older on in the
POMs, we switch to the newer one and do release testing around the older ones
that folks have an interest in supporting? If a certain module needs a specific
version of Guava (e.g. Cassandra tests), then we can mark that version at
test-time for that specific module.
I’m fine with that.
Guava has always been a special case in my mind - I think of it as part of the
environment, like the JVM and Java runtime, and therefore we try to work well
with whatever environment the container has chosen. But there’s no reason to
endorse old, buggy versions of Guava even if we can support them.
Also, we should have a plan to de-support old versions. “This the last release of
Calcite/Avatica that will support Guava x; next release we will require Guava y or
higher."
Julian
Thanks, Julian. I like your suggestions. Let me put this on queue and
see what concrete plan I can put together.
