Shay,
Any hints on what's coming down the pipe, and when you think/hope/plan to
have a 1.0 release?
Regards,
Berkay Mollamustafaoglu
mberkay on yahoo, google and skype
Heya,
Thats a good question. Versioning is a funny thing, since different projects use versions in a different manner. In terms of using elasticsearch "in production", it certainly can be used today (and many users do). What are you missing from what you qualify as a 1.0 release?
As for features coming down the pipe, there are the small but important enhancements that I have been thinking about. They are usually driven by users, and if they miss something, I think about how best to solve it.
As for the really big ones, I have several on my mind. The problem with those is that they are usually things that I don't know if they can even be implemented in a meaningful manner :). For example, percolator was on my mind for a long time (and some users even asked for it), but I was not sure if it can be implemented in a proper manner before I sat down and tackled it. So, I usually prefer not to talk about them too much, just so there won't be too big a disappointment if they don't make it.
Is there anything specific you are after?
-shay.banon
On Friday, February 25, 2011 at 3:19 AM, Berkay Mollamustafaoglu wrote:
Shay,
Any hints on what's coming down the pipe, and when you think/hope/plan to have a 1.0 release?
Regards,
Berkay Mollamustafaoglu
mberkay on yahoo, google and skype
From my perspective, Elasticsearch does not miss any features to qualify for
a 1.0 release. I believe perception is important for any product, and 0.
releases give the impression that product is immature, under development and
may not be stable. It makes it harder to convince others in an organization
that it is OK to use it in production.
So a 1.0 release would be mostly signaling readiness of ES for production
use. I get asked about a stable branch, whether it would be maintained (bug
fixes as opposed to upgrade to latest version)
I personally love the fast pace of change and the new features, but in the
level ES has reached, a 1.0 release may make it more attractive for larger
set of users beyond early adopters.
Just food for thought..
Berkay
Regards,
Berkay Mollamustafaoglu
mberkay on yahoo, google and skype
On Sat, Feb 26, 2011 at 3:20 PM, Shay Banon shay.banon@elasticsearch.comwrote:
Heya,
Thats a good question. Versioning is a funny thing, since different
projects use versions in a different manner. In terms of using elasticsearch
"in production", it certainly can be used today (and many users do). What
are you missing from what you qualify as a 1.0 release?As for features coming down the pipe, there are the small but important
enhancements that I have been thinking about. They are usually driven by
users, and if they miss something, I think about how best to solve it.As for the really big ones, I have several on my mind. The problem with
those is that they are usually things that I don't know if they can even be
implemented in a meaningful manner :). For example, percolator was on my
mind for a long time (and some users even asked for it), but I was not sure
if it can be implemented in a proper manner before I sat down and tackled
it. So, I usually prefer not to talk about them too much, just so there
won't be too big a disappointment if they don't make it.Is there anything specific you are after?
-shay.banon
On Friday, February 25, 2011 at 3:19 AM, Berkay Mollamustafaoglu wrote:
Shay,
Any hints on what's coming down the pipe, and when you think/hope/plan to
have a 1.0 release?Regards,
Berkay Mollamustafaoglu
mberkay on yahoo, google and skype
So a 1.0 release would be mostly signaling readiness of ES for
production use. I get asked about a stable branch, whether it would be
maintained (bug fixes as opposed to upgrade to latest version)
True, but the first 1.0 release also means that there is a commitment to
API stability.
While the API is pretty stable these days, there are still changes like
the geopoint switch from [lat,lon] to [lon,lat]. Making that change
once 1.0 is released would mean a long deprecation process.
So it is a toss up between flexible change and general acceptability.
clint
Right, agreed on both fronts. A 1.0 version can provide a good perception. And the next version can be 2.0 right away, I guess, with 1.0 branch for important fixes.
The perception is an important one, which needs to be addressed. We'll see, maybe 1.0 can be moved to an earlier date (a few months from now?)
On Sunday, February 27, 2011 at 8:35 PM, Clinton Gormley wrote:
So a 1.0 release would be mostly signaling readiness of ES for
production use. I get asked about a stable branch, whether it would be
maintained (bug fixes as opposed to upgrade to latest version)True, but the first 1.0 release also means that there is a commitment to
API stability.While the API is pretty stable these days, there are still changes like
the geopoint switch from [lat,lon] to [lon,lat]. Making that change
once 1.0 is released would mean a long deprecation process.So it is a toss up between flexible change and general acceptability.
clint
Hi shay
Maybe, a web console admin?
On Feb 27, 3:35 pm, Shay Banon shay.ba...@elasticsearch.com wrote:
Right, agreed on both fronts. A 1.0 version can provide a good perception. And the next version can be 2.0 right away, I guess, with 1.0 branch for important fixes.
The perception is an important one, which needs to be addressed. We'll see, maybe 1.0 can be moved to an earlier date (a few months from now?)
On Sunday, February 27, 2011 at 8:35 PM, Clinton Gormley wrote:
So a 1.0 release would be mostly signaling readiness of ES for
production use. I get asked about a stable branch, whether it would be
maintained (bug fixes as opposed to upgrade to latest version)True, but the first 1.0 release also means that there is a commitment to
API stability.While the API is pretty stable these days, there are still changes like
the geopoint switch from [lat,lon] to [lon,lat]. Making that change
once 1.0 is released would mean a long deprecation process.So it is a toss up between flexible change and general acceptability.
clint
On 28 February 2011 08:35, tfreitas tfreitas@gmail.com wrote:
Hi shay
Maybe, a web console admin?
On that note I was thinking along the lines of how the AWS APIs have good
scripting tools that just wrap the APIs. It's very handy, particularly for
automating deployments for ops folks, and general management.
http://mobz.github.com/elasticsearch-head/
Works great.
Regards,
Dan
On Sun, Feb 27, 2011 at 2:35 PM, tfreitas tfreitas@gmail.com wrote:
Hi shay
Maybe, a web console admin?
On Feb 27, 3:35 pm, Shay Banon shay.ba...@elasticsearch.com wrote:
Right, agreed on both fronts. A 1.0 version can provide a good
perception. And the next version can be 2.0 right away, I guess, with 1.0
branch for important fixes.The perception is an important one, which needs to be addressed. We'll
see, maybe 1.0 can be moved to an earlier date (a few months from now?)On Sunday, February 27, 2011 at 8:35 PM, Clinton Gormley wrote:
So a 1.0 release would be mostly signaling readiness of ES for
production use. I get asked about a stable branch, whether it would
be
maintained (bug fixes as opposed to upgrade to latest version)True, but the first 1.0 release also means that there is a commitment
to
API stability.While the API is pretty stable these days, there are still changes like
the geopoint switch from [lat,lon] to [lon,lat]. Making that change
once 1.0 is released would mean a long deprecation process.So it is a toss up between flexible change and general acceptability.
clint
Both the timing and the dual (stable 1.x vs dev 2.x) approach sounds right
to me.
Regards,
Berkay Mollamustafaoglu
mberkay on yahoo, google and skype
On Sun, Feb 27, 2011 at 2:35 PM, Shay Banon shay.banon@elasticsearch.comwrote:
Right, agreed on both fronts. A 1.0 version can provide a good
perception. And the next version can be 2.0 right away, I guess, with 1.0
branch for important fixes.The perception is an important one, which needs to be addressed. We'll see,
maybe 1.0 can be moved to an earlier date (a few months from now?)On Sunday, February 27, 2011 at 8:35 PM, Clinton Gormley wrote:
So a 1.0 release would be mostly signaling readiness of ES for
production use. I get asked about a stable branch, whether it would be
maintained (bug fixes as opposed to upgrade to latest version)True, but the first 1.0 release also means that there is a commitment to
API stability.While the API is pretty stable these days, there are still changes like
the geopoint switch from [lat,lon] to [lon,lat]. Making that change
once 1.0 is released would mean a long deprecation process.So it is a toss up between flexible change and general acceptability.
clint
Hi Paul
On that note I was thinking along the lines of how the AWS APIs have
good scripting tools that just wrap the APIs. It's very handy,
particularly for automating deployments for ops folks, and general
management.
I was thinking of writing a Perl script which could be used from the
command line.
What kind of operations would you like to see this script support?
clint
On 28 February 2011 20:39, Clinton Gormley clinton@iannounce.co.uk wrote:
Hi Paul
On that note I was thinking along the lines of how the AWS APIs have
good scripting tools that just wrap the APIs. It's very handy,
particularly for automating deployments for ops folks, and general
management.I was thinking of writing a Perl script which could be used from the
command line.What kind of operations would you like to see this script support?
the ones at top of mind:
- mapping related changes (I'm thinking of during schema upgrades)
- shutdown - bit obvious...
- changing replicas
- closing, optimizing indexes
- creating aliases
- Querying health
these are ones I can think of after a few glasses of red. 
cheers,
Paul
I'll pass that on to Ben, he'll be pleased to here..
On 28 February 2011 09:36, Dan Young danoyoung@gmail.com wrote:
http://mobz.github.com/elasticsearch-head/
Works great.
Regards,
Dan
On Sun, Feb 27, 2011 at 2:35 PM, tfreitas tfreitas@gmail.com wrote:
Hi shay
Maybe, a web console admin?
On Feb 27, 3:35 pm, Shay Banon shay.ba...@elasticsearch.com wrote:
Right, agreed on both fronts. A 1.0 version can provide a good
perception. And the next version can be 2.0 right away, I guess, with 1.0
branch for important fixes.The perception is an important one, which needs to be addressed. We'll
see, maybe 1.0 can be moved to an earlier date (a few months from now?)On Sunday, February 27, 2011 at 8:35 PM, Clinton Gormley wrote:
So a 1.0 release would be mostly signaling readiness of ES for
production use. I get asked about a stable branch, whether it would
be
maintained (bug fixes as opposed to upgrade to latest version)True, but the first 1.0 release also means that there is a commitment
to
API stability.While the API is pretty stable these days, there are still changes
like
the geopoint switch from [lat,lon] to [lon,lat]. Making that change
once 1.0 is released would mean a long deprecation process.So it is a toss up between flexible change and general acceptability.
clint