# Breaking Java API changes in release notes? **URL:** \ **Category:** Elasticsearch\ **Created:** [November 15, 2010, 6:19pm UTC](https://discuss.elastic.co/t/breaking-java-api-changes-in-release-notes/3572 "2010-11-15T18:19:58Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [November 15, 2010, 6:19pm UTC](https://discuss.elastic.co/t/breaking-java-api-changes-in-release-notes/3572/1 "2010-11-15T18:19:58Z")
Hey, The release notes do a great job of calling out any breaking changes in terms of gateway format or config files: > **[elastic/elasticsearch](https://github.com/elastic/elasticsearch)** > > elasticsearch - Open Source, Distributed, RESTful Search Engine However, it'd be great if any updates that impact the compatibility of Java API protocols were called out, as well. For example, I am on master from last week and am moving up to the current master and the only way to know if the Java APIs are still compatible is to just give it a shot. My preference is to perform a rolling update, but if I knew there was an incompatibility would have to bring down the whole cluster and upgrade it all at the same time. Along these same lines and probably a better approach, it'd be best if the APIs detected you were attempting to talk to an incompatible version and log out the failure and refuse to join. Thanks, Paul ---
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [November 15, 2010, 8:08pm UTC](https://discuss.elastic.co/t/breaking-java-api-changes-in-release-notes/3572/2 "2010-11-15T20:08:01Z")
Looks like the same incompatibility can exist with the cluster metadata and config. Guess the correct approach is to always update the entire cluster and any Java node based clients at the same time? On Nov 15, 11:19 am, Paul [ppea...@gmail.com](mailto:ppea...@gmail.com) wrote: > Hey, > The release notes do a great job of calling out any breaking changes > in terms of gateway format or config files:[GitHub - elastic/elasticsearch: Free and Open, Distributed, RESTful Search Engine](https://github.com/elasticsearch/elasticsearch/wiki/Release-notes) > > However, it'd be great if any updates that impact the compatibility of > Java API protocols were called out, as well. > > For example, I am on master from last week and am moving up to the > current master and the only way to know if the Java APIs are still > compatible is to just give it a shot. My preference is to perform a > rolling update, but if I knew there was an incompatibility would have > to bring down the whole cluster and upgrade it all at the same time. > > Along these same lines and probably a better approach, it'd be best if > the APIs detected you were attempting to talk to an incompatible > version and log out the failure and refuse to join. > > Thanks, > Paul ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [November 16, 2010, 8:55am UTC](https://discuss.elastic.co/t/breaking-java-api-changes-in-release-notes/3572/3 "2010-11-16T08:55:46Z")
Yes, at least currently, this is the case. On Mon, Nov 15, 2010 at 10:08 PM, Paul [ppearcy@gmail.com](mailto:ppearcy@gmail.com) wrote: > Looks like the same incompatibility can exist with the cluster > metadata and config. > > Guess the correct approach is to always update the entire cluster and > any Java node based clients at the same time? > > On Nov 15, 11:19 am, Paul [ppea...@gmail.com](mailto:ppea...@gmail.com) wrote: > > > Hey, > > The release notes do a great job of calling out any breaking changes > > in terms of gateway format or config files: > > [GitHub - elastic/elasticsearch: Free and Open, Distributed, RESTful Search Engine](https://github.com/elasticsearch/elasticsearch/wiki/Release-notes) > > > > However, it'd be great if any updates that impact the compatibility of > > Java API protocols were called out, as well. > > > > For example, I am on master from last week and am moving up to the > > current master and the only way to know if the Java APIs are still > > compatible is to just give it a shot. My preference is to perform a > > rolling update, but if I knew there was an incompatibility would have > > to bring down the whole cluster and upgrade it all at the same time. > > > > Along these same lines and probably a better approach, it'd be best if > > the APIs detected you were attempting to talk to an incompatible > > version and log out the failure and refuse to join. > > > > Thanks, > > Paul ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [November 16, 2010, 10:24am UTC](https://discuss.elastic.co/t/breaking-java-api-changes-in-release-notes/3572/4 "2010-11-16T10:24:13Z")
On Tue, 2010-11-16 at 10:55 +0200, Shay Banon wrote: > Yes, at least currently, this is the case. > > ``` > Guess the correct approach is to always update the entire > cluster and > any Java node based clients at the same time? > > ``` Would it not be a good idea to introduce an API version check at the moment that a node tries to join a cluster. If the cluster it connects to is using a different version of API, then it could throw an error explaining the issue. We've seen a few emails from people who have inadvertently mixed versions, with cryptic results, and this error would make it clearer what the problem is. Later, the versioning could make it possible to handle different versions gracefully, but this seems to me to be a reasonable half way point, no? clint -- Web Announcements Limited is a company registered in England and Wales, with company number 05608868, with registered address at 10 Arvon Road, London, N5 1PR. ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [November 17, 2010, 9:59am UTC](https://discuss.elastic.co/t/breaking-java-api-changes-in-release-notes/3572/5 "2010-11-17T09:59:00Z")
Yes, agreed. Requires some careful thinking, but certainly possible. On Tue, Nov 16, 2010 at 12:24 PM, Clinton Gormley [clinton@iannounce.co.uk](mailto:clinton@iannounce.co.uk)wrote: > On Tue, 2010-11-16 at 10:55 +0200, Shay Banon wrote: > > > Yes, at least currently, this is the case. > > > > ``` > > Guess the correct approach is to always update the entire > > cluster and > > any Java node based clients at the same time? > > > > ``` > > Would it not be a good idea to introduce an API version check at the > moment that a node tries to join a cluster. If the cluster it connects > to is using a different version of API, then it could throw an error > explaining the issue. > > We've seen a few emails from people who have inadvertently mixed > versions, with cryptic results, and this error would make it clearer > what the problem is. > > Later, the versioning could make it possible to handle different > versions gracefully, but this seems to me to be a reasonable half way > point, no? > > clint > > -- > Web Announcements Limited is a company registered in England and Wales, > with company number 05608868, with registered address at 10 Arvon Road, > London, N5 1PR. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:16am UTC](https://discuss.elastic.co/t/breaking-java-api-changes-in-release-notes/3572/6 "2017-07-06T04:16:23Z")
Closed on July 6, 2017, 4:16am UTC