Make the client better support multiple different versions

[sumologic]

Make the client better support multiple different versions

[rcoh]

Pasting my response:

The right answer is to maintain multiple branches for each version -- it's what all the other major ES libraries do. I'd rather not try to extract some shared classes and try to have one piece of code support multiple versions -- given the way we test and build the repo it just isn't pragmatic.

In a world where we were trying to make the best possible public library, we'd maintain a 2.x branch and a 5.x branch. I'm not saying we should necessarily go to that length. Anyone still on 1.x won't be able to use the new releases (full stop). A 1.x branch will be created if it hasn't already to backport changes to 1.x.

[davidcarltonsumo]

The scenario that I'm worried about with the multiple branch situation is how the client can handle upgrading elasticsearch server versions. Depending on how we do the upgrade, we might actually have the same java binary talking to a 1.x and 2.x server (or 2.x and 5.x) simultaneously; that java code can only have one version of the elasticsearch-client jar in its class path. And even if we do the upgrade in a way that there's only one elasticsearch server version running at any given time, I'd prefer not to structure things so that, when we flip the switch on the server, we also have to change our deployed code in lockstep with flipping the switch on the server.

[rcoh]

That's a good point. What about having a transition version for 1-2 and 2-5? It wouldn't get changes except bug fixes.

…

On Thu, Jun 1, 2017, 11:42 AM David Carlton ***@***.***> wrote: The scenario that I'm worried about with the multiple branch situation is how the client can handle upgrading elasticsearch server versions. Depending on how we do the upgrade, we might actually have the same java binary talking to a 1.x and 2.x server (or 2.x and 5.x) simultaneously; that java code can only have one version of the elasticsearch-client jar in its class path. And even if we do the upgrade in a way that there's only one elasticsearch server version running at any given time, I'd prefer not to structure things so that, when we flip the switch on the server, we also have to change our deployed code in lockstep with flipping the switch on the server. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#127 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeFZw1X7lraGQgQjZJvRTYjbgsePhCzks5r_wYngaJpZM4NlvjJ> .

[davidcarltonsumo]

yeah, that seems entirely reasonable to me. I don't see any reason to try to support all versions at once, the transitions are what matter.