Elasticsearch-net: [meta] 7.0.0 GA release

[Mpdreamz]

Meta ticket for 7.0.0 GA

PRs

• [x] Secure String - https://github.com/elastic/elasticsearch-net/pull/3825
• [x] Dynamic cluster state - https://github.com/elastic/elasticsearch-net/pull/3824
• [x] Upgrade assistant - https://github.com/elastic/elasticsearch-net/pull/3822
• [x] Serialisation - https://github.com/elastic/elasticsearch-net/pull/3815
• [x] Low level deprecated paths - https://github.com/elastic/elasticsearch-net/pull/3814
• [x] DiagnosticSource support

Other

• [x] Check nuspec inclusion with DiagnosticSource
• [x] Breaking changes list (generate from published artifact)
  
  
  
  • Documentation change to 7.x
  
  
• [x] [Go through the Elasticsearch 7.0.0 release notes](https://www.elastic.co/guide/en/elasticsearch/reference/current/release-notes-7.0.0.html)
• [x] Write release notes for NEST / Elasticsearch.Net clients
• [x] Blog post for release, major topics
  
  
  
  • Serialisation
  
  
  • IsValid changes
  
  
  • Types removal
  
  
  • DiagnosticSource
  
  
  • Namespacing (+Upgrade Assistant)
  
  
  • Response Interfaces are gone
  
  
  • High to Low level dispatch changes
  
  
• [x] Ensure TODOs are addressed in codebase
• [x] Check Obsolete usage - https://github.com/elastic/elasticsearch-net/pull/3880
• [x] Review Target Frameworks (netstandard, check possiblity for net461 / netcoreapp2.2)
• [x] Highlight field deserialisation refactoring

[ffMathy]

How is this going?

[codebrain]

Looking at the default connection limit of 80, this seems to have been updated approx 2 years ago on this PR: https://github.com/elastic/elasticsearch-net/pull/2785

After looking into this I am having trouble finding decent guidance on what a sensible default value to be, the consensus is that it is very much use case dependant.

I think the best route forward here is to leave the default of 80 intact and prompt users to override the default if they are experiencing issues.

[codebrain]

7.0.0-beta1 has been released:
https://github.com/elastic/elasticsearch-net/releases/tag/7.0.0-beta1

Available from Nuget.

[lummar]

7.0.0-beta1 has been released:
https://github.com/elastic/elasticsearch-net/releases/tag/7.0.0-beta1

Available from Nuget.

Bunches of methods removed from IElasticClient in the 7.0.0-beta1 Nuget package, was that expected to happen?

[russcam]

@lummar which methods in particular? It's likely that they've just been moved.

The 7.x client is still a beta prerelease so there are potentially still breaking changes going into it, but once it's GA, which we're working hard to make happen ASAP, backwards binary compatibility will be maintained for the 7.x major lineage.

[mtbitcoin]

@russcam for instance

client.IndexExists("indexname").Exists ... or client.CreateIndex("indexname") ...

A lot of the official examples out there still reference the above methods

[russcam]

@mtbitcoin we will publish release notes to help with this when 7.x reaches GA. For now, please take a look at the 7.0.0-beta1 release notes.

The rationale for making this change is that the Elasticsearch API is now well over 200 endpoints, and having all of these as methods on the root of the client has become increasingly unwieldy over time, and is only likely to become more so as further APIs are introduced in the future.

Within the Elasticsearch rest specifications, the APIs are namespaced into modules, which many of the official clients already use to logically group a set of APIs that should belong together e.g. APIs that operate on indices are grouped under Indices, The change in the .NET client, whilst I totally understand will require changes when upgrading from a previous version to 7.x, will hopefully result in an easier to navigate collection of APIs going forward.

client.IndexExists("indexname").Exists

Use

```c#
client.Indices.Exists("indexname").Exists

> client.CreateIndex("indexname")

```c#
client.Indices.Create("indexname")

[saniokOnta]

I have just installed the 7.0.0-beta1 and seen that all ElasticClient responses are concrete classes instead of interfaces.

We cannot mock the ElasticClient methods for unit testing anymore, because the response types have internal Set for their properties.

How would we create unit tests for types which use IElasticClient? Any idea?

[russcam]

@Mpdreamz @codebrain do we want to consider the Diagnostics changes (https://github.com/elastic/elasticsearch-net/issues/3564) for 7.0 GA? Implementation may have impliciations the audit implementation

[Mpdreamz]

@russcam yeah let's get that one in

[codebrain]

7.0 is now GA!
https://github.com/elastic/elasticsearch-net/releases/tag/7.0.0

Closing this ticket and will re-open a new ticket for 7.1 meta tracking.