On Thu, Dec 19, 2013 at 3:15 PM, [email protected] < [email protected]> wrote:
> From the ES version numbering scheme, it is impossible to predict > consequences of updates. > > Whenever a minor release appears, it may or may not break existing code, > especially in plugins. > > So my humble request is to label releases as "feature releases" (with > expected API breakages), "bugfix releases" (without any API change), maybe > also "security releases" (a bugfix release that is of highest priority and > supersedes all previous releases) > > Also a problematic point from the perspective of migration planning is the > visibility of changes in the internal structures, most important, the > binary transport protocol and the Lucene version index format. For better > convenience, this should be somehow reflected in the ES versioning > numbering scheme. > > I hope for a more transparent release numbering scheme after 1.0.0 > I wonder if Elasticsearch could use semver, at least from the perspective of the non-beta portions of the rest api. Personally I don't have the same feelings about the rest API but understand the argument. I need rolling upgrades to work though. Nik -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAPmjWd0uACAZFXi6wvjzaU4tUuSvoEUvytezmueVxQzWW1chYg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
