> 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
