Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Release 0.5.5

  • Loading branch information...
1 parent 53cf972 commit f185eda7f7e37090085aab0cc526b65f4067ad72 @karmi committed
Showing with 7 additions and 11 deletions.
  1. +7 −11 lib/tire/version.rb
18 lib/tire/version.rb
@@ -1,18 +1,14 @@
module Tire
- VERSION = "0.5.4"
+ VERSION = "0.5.5"
- * Added the support for the Count API
- * Escape single quotes in `to_curl` serialization
- * Added JRuby compatibility
- * Added proper `as_json` support for `Results::Collection` and `Results::Item` classes
- * Added extracting the `routing` information in the `Index#store` method
- * Refactored the `update_index` method for search and persistence integration
- * Cast collection properties in Model::Persistence as empty Array by default
- * Allow passing `:index` option to `MyModel.import`
- * Update to Mocha ~> 0.13
- * Update to MultiJson ~> 1.3
+ * Improved documentation
+ * Improved isolation of Tire methods in model integrations
+ * Improved handling of times/dates in `Model::Persistence`
+ * Added support for "Put Mapping" and "Delete mapping" APIs
+ * Added escaping document IDs in URLs
+ * Allowed passing URL options when passing search definition as a Hash

6 comments on commit f185eda



I know Tire is not officially stable yet (< 1.0.0) and thus SemVer doesn't really apply here, but adding new features should increment the minor number, not the patch number, don't you think ?


Technically, yes -- but I try to increase the minor number for backwards incompatible or large changes... I care more about not breaking stuff for people and making Tire play nice with Gemfile restrictions (~> 0.5) then strictly conforming to SemVer. What do you think?


OK, I seem what you mean and it makes sense.
Maybe, when pre-1.0, we could use a four digits versioning scheme, just like SemVer, but with a leading 0. to indicate the unstable version.


There would have to be a really compelling reason to switch the versioning scheme right now :) Is your issue philosophical or are there any practical issues with the current versioning scheme? (Side note, many people run directly from Github.)


Yeah, my issue is more philosophical than practical.

I guess I'm not comfortable with libraries that stay in the pre-1.0 for a long time, even if there are a lot of people using it in production. No piece of software is ever perfect, bug free, … And I don't mind having libraries with major versions coming every few month if the versioning is clear enough to rely on.

That said, your are the one who is putting the effort in this, so you can do what suits you best ;)
Thank you very much for your amazing work that helps me use Elasticsearch better/easier in my projects.


It still pains me to have to step through the history of this file instead of consulting a changelog, and having references to relevant commits/issues linked :disappointed:

Please sign in to comment.
Something went wrong with that request. Please try again.