> On Oct 11, 2018, at 12:49 PM, Patrick Rhomberg <prhomb...@pivotal.io> wrote:
>
>> We need testing of Geode (both old and current versions) on older JVMs
> talking to Geode on newer JVMs.
>
> It would be nice to support this, but I'm not sure we should. We support
> rolling upgrades between versions of Geode, but I'm not convinced we should
> support JDK mismatch within a live cluster.
There is a long list of capabilities built into Geode that work together to
provide 24x7x365 operation with zero downtime *ever*. This is why we carefully
test backwards compatibility across various dimensions and ensure that users
can do rolling upgrades from version to version.
If we throw away support for rolling JDK versions (which we’ve always
supported) then we leave our users with a difficult decision: schedule an
outage, fail-over to a secondary cluster, or stay on jdk 8 forever.
Is there a technical reason preventing us from supporting rolling JDK upgrades?
If so, can we find a way to work around this?
Anthony
