I think it’s a good idea to go ahead and rename it. Even if 6.x doesn’t make breaking changes, 7.x may. And I’d rather not have an ElasticSearchClient that works for 5.x and 6.x and then an ElasticSearchClient_7 that deals with 7. It makes it look like the simply named ElasticSearchClient is generic and will work with any version. This is what we did with the PublishKafka* processors and it has only caused confusion.
Sent from my iPhone > On Jun 10, 2018, at 8:20 AM, Mike Thomsen <[email protected]> wrote: > > I think types are required in 5.X and optional in 6.X. By 8.X types are > going to be firmly eliminated, so that's at least one area of research that > needs to be done I suppose. > > On Sun, Jun 10, 2018 at 7:53 AM Sivaprasanna <[email protected]> > wrote: > >> I feel if the upgrade from 5.x to 6.x client doesn't introduce any breaking >> changes, we can continue with the name that we are having now. >> >> - >> Sivaprasanna >> >> On Sun, Jun 10, 2018 at 5:16 PM, Mike Thomsen <[email protected]> >> wrote: >> >>> The current implementation uses the last stable release of the 5.X client >>> from Elastic, and 6.X is already mature so we'll need to be able to have >>> room to create a new implementation copy that uses that client if there >> are >>> things we have to change between them. So does it make sense to throw in >> a >>> new ticket to rename the service to something that indicates that this >>> implementation is officially for 5.X? As of 1.6 I think only one >> processor, >>> JsonQueryElasticSearch, uses it so not many uses would likely be impacted >>> yet. >>> >>> Thanks, >>> >>> Mike >>> >>
