Support compatibility test for JDBC driver

[mark-vieira]

Forwards compatibility was added to our JDBC driver starting in version 7.7.0 (see #56223). The compatibility guarantee being that for any given version of the driver, it should support (mostly) communication for future versions of Elasticsearch of the same major version. For example, version 7.7.0 of the driver should be able to talk to Elasticearch nodes of version 7.7.1, 7.8.0, 7.8.1, 7.9.0 and so on...

Currently, there is no automated testing in place to ensure we maintain forwards compatibility. It's also not completely clear where, or how these tests should run. Currently, the build only supports backwards compatibility. That is, testing branch code against assets or artifacts from earlier versions or branches. Building or resolving artifacts to test against from future branches currently isn't supported, since, for example, the 7.x branch has no knowledge of the code in master.

We'll need to sort out a few things here, such as which direction we test in. Do we do backwards testing, where in which future branches grab the older JDBC drivers and run the tests, or forwards testing, where older branches grab the new Elasticsearch distribution and run the tests? Much of this is implementation detail, but it has some semantic impact, as with the former method, a failure in a given branch generally points to an incompatible change made in a different branch (but not necessarily). Going the latter route would require more effort, since we'd need to add support to build unreleased artifacts from future branches, which we currently don't do.

cc @matriv

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Build)

[elasticmachine]

Pinging @elastic/es-ql (:Query Languages/SQL)

[mark-vieira]

It's possible that this somewhat overlaps with what @jakelandis is doing with REST compatibility, as this is another type of forwards compatibility, although implemented a bit differently. Again, in that case (correct me if I'm wrong) newer branches grab the artifact (in this case the rest specs) from the older branch and run them against the current version.

[rjernst]

We'll need to sort out a few things here, such as which direction we test in. Do we do backwards testing, where in which future branches grab the older JDBC drivers and run the tests, or forwards testing, where older branches grab the new Elasticsearch distribution and run the tests?

I think we should continue with backwards compatibility testing, for a few reasons:

• The compatibility layer is implemented in the "future" version. ie in 7.x, we have the compatibility layer with earlier versions, ie backwards compatibility. Thus that is where 7.x should be tested against all the versions it is compatible with.
• As you say, backcompat is the model of tests that we already have. We already have build infrastructure for iterating over compatible versions to build tests against each version.
• It fits better with our branching model. We rarely commit directly to release branches, but instead go through our unreleased branches. It is better to catch compatibility problems in the initial commit rather than only once we backport to a release branch.

[matriv]

FYI I've opened: #56872, to "isolate" the jdbc integration tests and avoid hidden bugs because of possible unnecessary pulled in dependencies, and to prepare for the support compatibility testing.

[matriv]

I also agree with keeping the bwc scheme. So for example: for 7.8 we can check for each 7.7.x and 7.8.x released versions of ES nodes with the [7.7.0 -> es node version - 1].

We'd like to have something soon as new features are blocked by this (for example date_nanos support PR awaits on this).