You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if elastic/elasticsearch#38413 lands it would be better if we put API's that are not stable in a separate package that can be versioned differently.
Currently we do lockstep releases with Elasticsearch Major.Minor this means we can not introduce breaking changes until a new Major of Elasticsearch is released.
Experimental and beta API's in Elasticsearch are subject to breaking changes in Minor releases. So that puts us in a bind. Historically we've found ways to accommodate this when it arose.
Experimental and beta API's in practice do not change that much though and so a separate package could proof overkill.
The text was updated successfully, but these errors were encountered:
This approach was changed recently and the following section added to the README
Low Level Client Compatibility
The Elasticsearch.Net low level client will expose functionality in REST APIs that are marked as either experimental or beta. This functionality is marked as such using the XML documentation comments, which contains the stability and a description of the compatibility guarantees. Examples below:
/// Note: Experimental within the Elasticsearch server, this functionality is experimental and may be changed or removed completely in a future release. Elastic will take a best effort approach to fix any issues, but experimental features are not subject to the support SLA of official GA features. This functionality is subject to potential breaking changes within a minor version, meaning that your referencing code may break when this library is upgraded.
/// Note: Beta within the Elasticsearch server, this functionality is in beta and is subject to change. The design and code is less mature than official GA features and is being provided as-is with no warranties. Beta features are not subject to the support SLA of official GA features. This functionality is subject to potential breaking changes within a minor version, meaning that your referencing code may break when this library is upgraded.
If you use this experimental or beta functionality, by taking a dependency on it within your code, you are exposing yourself to the potential for binary breaking changes within that major version.
Therefore the intention is to ship experimental and beta packages in the low level client, with the above caveat, and then look to introduce a Nest.Experimental package at a later date.
if elastic/elasticsearch#38413 lands it would be better if we put API's that are not
stable
in a separate package that can be versioned differently.Currently we do lockstep releases with Elasticsearch
Major.Minor
this means we can not introduce breaking changes until a newMajor
of Elasticsearch is released.Experimental and beta API's in Elasticsearch are subject to breaking changes in
Minor
releases. So that puts us in a bind. Historically we've found ways to accommodate this when it arose.Experimental and beta API's in practice do not change that much though and so a separate package could proof overkill.
The text was updated successfully, but these errors were encountered: