Make the client better support multiple different versions

[CCheSumo]

Quote @davidcarltonsumo here in the 2.3 upgrade PR #126

So I think this is fine, especially since 1.6 is such an old version.

Having said that, given that the client is pure REST, it seems like we should be able to design it to be able to support multiple different versions, and that we might need to do that. I haven't looked in detail at which classes would have to move, but it feels to me like there's probably a tractable subset of the classes that we could put in packages whose names include a version number, and then we could expose a version of RestlasticSearchClient in that directory that people could use to interact with a specific version and also have a version in its current location that refers to the current version. And then, when we add support for a new version, we could just copy the files from the previous version wholesale to the package for the new version, not trying to be clever about reducing duplication or anything.

I'm not completely sure about the details, admittedly. E.g. #121 changes the state machine, so that makes me not completely confident that we'd be able to do this in a way that limits scope. (I guess the flip side is that it's also not completely obvious to me that it would be awful to copy basically everything when upgrading versions!) And it's not like there are that many serious changes between versions (at least if this plus #121 is representative of version changes), so maybe it's overkill - maybe we could just leave in support for old interfaces as well as new interfaces while using a uniform client. And, finally, there's the test issue - presumably when testing, we would have to specify a single elasticsearch version to test against, which would make it hard to detect regressions against old versions. (Hopefully we could do it in a way to make it easy enough to manually test against old versions, ideally by just temporarily editing one number in the pom, but who knows.)

Anyways, I'm fine merging this specific one, given that there hopefully aren't too many other people on 1.6 and given that we believe that the new version should work with 1.6, it just might be a little less performant. But it feels like something where we'll want to develop a strategy at some point, possibly even for the 5.1 change?

This is very useful suggestion. We need a clear story around how to make the client better support multiple different versions. Especially, we we go for the 5.1 change.

[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.