Last week, we released the RC 1 to the nuget.org unstable feed. Today, we are happy to announce the general availability of 1.0 in the nuget stable channel!
No more separate *.Signed packages
All the assemblies are strong name signed by default. While we personally feel strong naming is up there with the invention of null as big mistakes, we can't escape the fact that it's a reality for some of our customers.
.NET, if you strong name your application or library, you can only use libraries that are also strongly named. If you do not, you are free to use signed and unsigned assemblies. The choice whether to strong name or not therefore comes down to servicing the most people.
We already see that great libraries like serilog that take a dependency on NEST are signed themselves.
So we promised no breaking changes between the RC and GA, but Nariman Haghighi sharply observed that our mapping of the Update API and updates inside the Bulk API were inconsistent and together iterated over a better syntax. This also has consequences for some of the other API's where you can pass an CLR Object to infer to id on. This used to be called
.Object() but has been renamed to the more descriptive
To make up for the breaking changes between the RC and GA, we released a little bit earlier!
Since the RC, we have improved the exception messages it throws to be as verbose as possible. Pings and sniffs exceptions are clearly distinguishable. The addresses of all the nodes that failed are now also visible in the exception message itself.
For the RC, we wrote a ton of unit tests throwing exceptions in deliberate places to be sure that exceptions that bubble out of the client are consistent:
MaxRetryExceptions when using connection pooling, and the actual exception when not regardless whether a synchronous or asynchronous method is called.
- While all of these passed when we released RC1, we found that the real world is hairier.
WebRequest, by default, only exposes 64kb of the response on error. If the error response exceeds that Exceptions were not properly thrown and errors were not properly set.
- 9 out of 10 times, the async methods from
IConnectionimplementations throw exceptions that result in tasks in faulted state. But if an exception occurs before any async work has been done they throw a hard exception that our transport layer did not properly recover from to failover to the next node.
We've added unit tests for these hard exceptions and wrote a ton of integration tests for timeouts and other connection related exceptions.
Better GeoShape mapping
Previously, NEST only allowed for a Coordinates object of type
IEnumerable<IEnumerable<double>> for shapes which only worked for a sub set of the GeoJSON objects that Elasticsearch supports. Rather than one GeoShape descriptor for all shape types, NEST now exposes a separate descriptor for each, accepting the correct coordinates structure for that type.
We're proud to announce that NEST is now CLS-Compliant! Read more about what that means here.
- We're already working hard on improving the documentation. Anders Østhus deserves a mention here as he put a lot of effort into the documentation around aggregations using NEST. Expect an update here soon.
- Sample application: also in the works is a real world example application that shows off many common tasks such as indexing from a REST API, searching, faceting/aggregation, and autocomplete, all using exciting new .NET features such as
OWIN, Nancyfx, Helios, ASP vNext, Azure, kudu, webjobs...the list of buzzwords continues. This application will be continuously deployed using the latest nuget package from myget. The purpose here is twofold — examples from this application will drive the new documentation and the continuous deploy of a real application using the latest build from our develop branch provides us with a lot of feedback.
- Map the few unmapped corners of the elasticsearch universe.
- Map new features — honestly, the pace at which our colleagues improve Elasticsearch is staggering!
- And last but not least, from
1.0.0forward, we'll try to release often while following SemVer to the best of our abilities.
If you have any issues, comments, or ideas, please don't forget to report them on our issue tracker on github.