[BUG] RangeQuery API broken after upgrade from 8.12.1 to 8.13.1 about elasticsearch-net HOT 6 CLOSED

@moonphone Fixed in 8.13.3

from elasticsearch-net.

We were wondering the same, upgraded from 8.12.1 to 8.13.1 suddenly a metric ton of breaking changes, like seriously?

from elasticsearch-net.

@moonphone @PatriQ94 We are sorry for the breaking changes, but sometimes they are unavoidable. Please have a look at the release notes to learn more about the reasons and for a documentation of the most important differences.

Regarding the actual issue, this seems similar to #8080. This change is not intended and I will make sure to restore the original behavior as best as I can.

In the meantime, you can use the following workaround:

.Range(new RangeQuery(new DateRangeQuery(new Field((Person x) => x.LastName))))

from elasticsearch-net.

@moonphone @PatriQ94 We are sorry for the breaking changes, but sometimes they are unavoidable.

The breaking changes reflect in the correct versioning numbers tho, so since there were imcompatible changes it was expected to have first number increased, not the second.

Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

from elasticsearch-net.

@PatriQ94 We know how semantic versioning works. However, in context of our clients, this is more complex and there is no perfect solution for that.

The major- and minor- versions are tied to the Elasticsearch server version. The patch version is independant.

This introduces issues as we simply can't wait for 1+ years (the usual Elasticsearch major version cycle) to push certain fixes or improvements.

We do of course try to minimize these breaking changes, but as I said, sometimes they are unavoidable. They are as well clearly mentioned in the release notes!

Please as well have a look at the clients breaking changes policy.

from elasticsearch-net.

As @flobernd describes, the versioning scheme for our client libraries is a trade-off. We have chosen to mirror the Elasticsearch versioning scheme for major and minor, as opposed to using an independent versioning scheme for clients; this makes it easier to determine compatibility between client and server software.

But the trade-off here is that the major and minor then don't strictly represent the semantic state of the client bundle itself, with regard to breaking changes and feature sets. That would perhaps require two sets of versions, strictly speaking.

Therefore we have no way to indicate, through the version alone, bigger changes which are necessary for other external reasons. We aim to minimise the times that these disruptions happen (and we do acknowledge that they are disruptive), and we try to fully document, and support users with code changes. But we can't avoid these entirely.

So while the point you make in the original post isn't "wrong" as such, please let us know if there are any specific code changes made by these releases that we can support you with.

from elasticsearch-net.