Elasticsearch-net: 7.0 release date?

Created on 11 Apr 2019  路  16Comments  路  Source: elastic/elasticsearch-net

Since 7.0 just came out of Elasticsearch, how long will it typically take for NEST to be updated to 7.0?

I see there's already a branch for it.

Most helpful comment

We will be releasing an alpha for 7.0.0 soon, looking at either tomorrow (friday) or monday baring anything major showing up.

If you want to move already: https://ci.appveyor.com/nuget/elasticsearch-net

  • has preview builds for 7.x e.g NEST version 7.1.0-ci20190411T072428.
  • Also hosts namespaced packages e.g NEST.v7 which allows you to more gradually move towards 7. All types in that package live in Nest7 or Elasticsearch.Net7.

Why an alpha?

There will be some more breaking changes after that release

  • grouping of NEST client methods, e.g now you have client.CloseJob and client.MachineLearningInfo() both pertain to Machine Learning but are hard to discover to we will move these to client.MachineLearning.CloseJob() and client.MachineLearning.Info(). Api's such as Search() Bulk() Index() won't be moved.

  • Lowlevel client will be cleaned up, we now generate methods for every PATH + httpmethod + Sync/Async making manouvring the lowlevel client a chore. We will introduce namespacing here as well as culling the ammount of generated methods

  • NEST has an interface for each response. Since all of these have one implementation this adds unnecessary weight to the assembly. They were added to facilitate mocking ages ago https://github.com/elastic/elasticsearch-net/pull/59 but we feel that mocking the client usually indicates you are not mocking components but implementations. cc @ThomasArdal

  • NEST uses a dispatch mechanism to go from highlevelclient.Search() to lowlevelClient.Search() this is all generated code thats adds to the weight of the dll that we like to cull as well see: #3658

Several more refactorings of internals and performance related improvements will go in as well.

So why release?

The current 7.x branch is tested against 7.0.0 and ready to go,

  • It deals with the type removal on Elasticsearch server side
  • Includes our move away from our internalized Json.NET (NEST) / SimpleJson (Elasticsearch.NET) to an internalized UTF8Json which brings performance improvements.

7.0.0 GA

No date is set but it has our complete focus at the moment but no target release date exists as of yet. We are looking for some (3-4) additional weeks to get all our desired changes in.

All 16 comments

We will be releasing an alpha for 7.0.0 soon, looking at either tomorrow (friday) or monday baring anything major showing up.

If you want to move already: https://ci.appveyor.com/nuget/elasticsearch-net

  • has preview builds for 7.x e.g NEST version 7.1.0-ci20190411T072428.
  • Also hosts namespaced packages e.g NEST.v7 which allows you to more gradually move towards 7. All types in that package live in Nest7 or Elasticsearch.Net7.

Why an alpha?

There will be some more breaking changes after that release

  • grouping of NEST client methods, e.g now you have client.CloseJob and client.MachineLearningInfo() both pertain to Machine Learning but are hard to discover to we will move these to client.MachineLearning.CloseJob() and client.MachineLearning.Info(). Api's such as Search() Bulk() Index() won't be moved.

  • Lowlevel client will be cleaned up, we now generate methods for every PATH + httpmethod + Sync/Async making manouvring the lowlevel client a chore. We will introduce namespacing here as well as culling the ammount of generated methods

  • NEST has an interface for each response. Since all of these have one implementation this adds unnecessary weight to the assembly. They were added to facilitate mocking ages ago https://github.com/elastic/elasticsearch-net/pull/59 but we feel that mocking the client usually indicates you are not mocking components but implementations. cc @ThomasArdal

  • NEST uses a dispatch mechanism to go from highlevelclient.Search() to lowlevelClient.Search() this is all generated code thats adds to the weight of the dll that we like to cull as well see: #3658

Several more refactorings of internals and performance related improvements will go in as well.

So why release?

The current 7.x branch is tested against 7.0.0 and ready to go,

  • It deals with the type removal on Elasticsearch server side
  • Includes our move away from our internalized Json.NET (NEST) / SimpleJson (Elasticsearch.NET) to an internalized UTF8Json which brings performance improvements.

7.0.0 GA

No date is set but it has our complete focus at the moment but no target release date exists as of yet. We are looking for some (3-4) additional weeks to get all our desired changes in.

How likely is that the the v6.x client would work against a v7 cluster assuming it doesn't hit any of the deprecated bits in elastic? Is this a worthwhile consideration or would using the pre-release 7/x library be preferable to this?

I'm looking forward to this release, it will be interesting how hard it will be to implement custom serialization naming :).

@andrewrimmer - we wouldn't recommend using a 6.x client against a 7.x cluster. You'd be better going with the alpha1 release as above ^

Any news on the release date?

@aaronsarkissian not at this time; we are working hard on getting to GA as soon as possible

We have released 7.0.0-alpha2!

Nuget: https://www.nuget.org/packages/NEST/7.0.0-alpha2
Release Notes: https://github.com/elastic/elasticsearch-net/releases/tag/7.0.0-alpha2

Thank you to everyone who has opened issues and submitted feedback with 7.x so far, it is very much appreciated 馃憤

Any news on the progress towards 7.0.0?

@kbandrew we're looking at putting out a beta in the _very near future_, and are collecting issues that must be addressed for this in #3563.

Closing this ticket, please keep tracking https://github.com/elastic/elasticsearch-net/issues/3563 for updates on the 7.0.0 release.

Just wondering, can this Nest v7 used for Elasticsearch v6.x? Or it must pair with Elasticsearch v7 and not backward compatible?

@leelcs I remember that they were saying to avoid using different versions of the Nest and Elasticsearch. In some cases, it just throws an error but even if it works in other cases, it may cause unexpected behaviors. The main reason may be from the JSON parser differences in 6 and 7.

Currently the 7.0.0 GA client is recommended for use against a 7.0.0 cluster.

That said, we did run the integration tests against a 7.1.1 cluster and they all passed, not every test passed when run against a 7.2.0 cluster - it will be very much at your own risk and not something we recommend if you choose to do this.

Using a 6.x client against a 7.x cluster, or vice-versa, is not recommended - as mentioned above there are very likely to be substantial differences in the requests/responses across major versions.

@codebrain I am surprised that the 7.0.0 client is not recommended for the latest 7.x version of elasticsearch. We have been waiting for the 7.x client, and assumed it would be better to install the latest version of elasticsearch (to pickup teething issues and fixes in elastic). Are you able to expand on what sort of tests were failing on 7.2?

My expectation was that there would be no breaking changes between minor versions of elasticsearch, is that not the case?

When I looked at the .net client compatibility matrix, I had assumed that any 7.x client should work against any 7.x cluster, and that if you are behind the elastic minor version that there may be new features not yet supported.

In terms of planning future cluster upgrades, should we always be looking to keep in perfect sync with the major.minor version of the .net client?

Do you have any idea when the 7.2 client might be ready?

In general is it a case of the .net client dropping when it is ready, or do you have rough targets on the lag between the elastic version dropping and when the .net client will add support?

Sorry for all the questions :), and thanks for all the great work.

@codebrain did you have any comments/thoughts on my previous post? Would it be better for me to raise a separate issue?

Was this page helpful?
0 / 5 - 0 ratings