-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/Elasticsearch 5.0 #247
Conversation
@@ -1,4 +1,4 @@ | |||
(defproject clojurewerkz/elastisch "3.0.0-beta2-SNAPSHOT" | |||
(defproject clojurewerkz/elastisch "5.0.0-alpha1-SNAPSHOT" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never alter version numbers in a pull request. It's up to the maintainer to decide when to do it and what the next version should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Matching the ES version seemed like the most sensible thing as they're matching versions across the elastic stack now. Having elasticsch 4.0.0 be compatible with 5.0.0 seems somewhat confusing.
I can revert if you want but it probably needs some discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not against jumping to 5.0
after 3.0
but I'm not going to accept a PR that changes project version. This is pull request etiquette 101.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since there will be no major Elastisch release for every ElasticSearch release in practice, the argument for matching versions only goes so far. But I've renamed the 4.0
milestone to 5.0
. It costs us nothing to jump a version once.
Thanks. So far this looks like less work that I'd expect. I assume this breaks compatibility with earlier ElasticSearch versions so will have to wait until Elastisch 5.0 (we'll skip 4.0). |
No problem. I don't think there's that many changes but I don't exercise all the APIs regularly. At the weekend I'm going to try and go through the list of breaking changes from 2.x -> now and try and clean up anything that's missing. For the meanwhile I'm just going to remove anything that's been deprecated/removed, once that's done I'll try and fill in the new features. |
Closing this as we've switched to https://github.com/mpenet/spandex at work. I'm however hoping to progress with this in my own time as I've got some personal projects that use this and it seems less work to upgrade. |
@Poogles I'm looking for an example with bulk requests using spandex please |
@faxm0dem https://gist.github.com/Poogles/8811de2040994391ae897f7386253200 Plus the bulk channel from the documentation. |
Doesn't look like anyones started work on this, and having upgraded at work I've bumped into a few issues. I know you're looking to get 3.0 out of the door first, this is just here as a pointer for anyone else who might be starting work on this.
It's a WIP as is, feel free to comment. All commits should be pretty self explanatory, will squash at a later point.
I'll probably just be looking at the rest API as I don't use the native API myself, if anyone can check that out it'd be great?