Thanks for your feedback. I just checked our your client. At the
moment you are just counting up the versions, right? My problem is,
that sometimes not only elasticsearch is breaking the API, but also I
rewrite parts of my client. To make it clear that a lot of things
changed, I would like to go to the next "higher" version number. But
this will also conflict in the future with the elasticsearch
Perhaps it's best to go with my own versioning but always mention the
compatibility as you do?
Still not sure what I should do
On Mar 28, 9:55 am, Clinton Gormley clin...@iannounce.co.uk wrote:
I'm the developer of the PHP Elastica client:https://github.com/ruflin/Elastica
At the moment I'm thinking about how to name the different versions of
Elastica. One approach would be to name my releases after the
I think this would make sense, because it always describes with which
version the client is compatible. But it does not describe when big
changes are implemented in Elastica.
What do you think? How should I name the different tags in Elastica?
I'm the developer of the Perl API ElasticSearch.pm, and I have a similar
issue, especially as occasionally the ElasticSearch API breaks backward
I've just gone for serial version numbers for the moment, and I mention
the target version of ES in the docs. My intention is to sync the
versioning when ES reaches 1.0.