: The point being: it's all been very informat up to now -- and that's
: probably for the best. policies should evolve over time based on real
: world situations that come up, and we're still in the process of doing
: that.
:
: Agreed, but now that the elephant has been identified in the
On Nov 25, 2009, at 11:30 AM, Chris Hostetter wrote:
: The point being: it's all been very informat up to now -- and
that's
: probably for the best. policies should evolve over time based
on real
: world situations that come up, and we're still in the process of
doing
: that.
:
:
: What would a 1.9 release mean in solr?
:
: Dooh -- after hitting send, i realized it would just mean:
: Whatever we would do for the next release, but say 'after this, old APIs won't
: be supported'
but even that is still a vague statement: are we talking about the
internal/plugin Java
Hi Guys,
The process should be as formal as the community dictates, but I can't help but
make the observation that increments in version numbers that are strange to
those with some knowledge of artifact versioning will only be stranger to those
without (i.e., adopters/users of SOLR).
To me,
On Nov 25, 2009, at 3:09 PM, Chris Hostetter wrote:
: What would a 1.9 release mean in solr?
:
: Dooh -- after hitting send, i realized it would just mean:
: Whatever we would do for the next release, but say 'after this,
old APIs won't
: be supported'
but even that is still a vague
Just to toss in my two cents...
I'd have to agree with Hoss here. In terms of versioning, I see no
reason that a major version bump in a dependency should cause a major
version bump in Solr - unless said bump causes major changes. I
haven't really looked at what's planned for Lucene 3.x
On Nov 24, 2009, at 9:07 AM, Colin Hynes wrote:
Just to toss in my two cents...
I'd have to agree with Hoss here. In terms of versioning, I see no reason
that a major version bump in a dependency should cause a major version bump
in Solr - unless said bump causes major changes.
It's got
On Nov 24, 2009, at 9:22 AM, Grant Ingersoll wrote:
On Nov 24, 2009, at 9:07 AM, Colin Hynes wrote:
Just to toss in my two cents...
I'd have to agree with Hoss here. In terms of versioning, I see no
reason that a major version bump in a dependency should cause a
major version bump in
On Nov 19, 2009, at 9:31 AM, Yonik Seeley wrote:
What should the next version of Solr be?
Options:
- have a Solr 2.0 with a lucene 3.x
+1. This gives us a chance to remove some deprecated stuff, too.
Grant Ingersoll wrote:
On Nov 19, 2009, at 9:31 AM, Yonik Seeley wrote:
What should the next version of Solr be?
Options:
- have a Solr 2.0 with a lucene 3.x
+1. This gives us a chance to remove some deprecated stuff, too.
What would be the current development branch of Solr
In practical terms, calling a release 2.0 means it will never finish.
One last feature! No, really! happens with 1.x. A Solr 2.0 will be
killed by Let's rewrite this!
http://en.wikipedia.org/wiki/Second-system_effect
On Mon, Nov 23, 2009 at 2:32 PM, Grant Ingersoll gsing...@apache.org wrote:
Is that a proposal to never leave 1.x :) I guess numbers do allow it ...
Lance Norskog wrote:
In practical terms, calling a release 2.0 means it will never finish.
One last feature! No, really! happens with 1.x. A Solr 2.0 will be
killed by Let's rewrite this!
On Mon, Nov 23, 2009 at 11:56 PM, Mark Miller markrmil...@gmail.com wrote:
Is that a proposal to never leave 1.x :) I guess numbers do allow it ...
Lance Norskog wrote:
In practical terms, calling a release 2.0 means it will never finish.
One last feature! No, really! happens with 1.x. A Solr
: regular trunk structure at some point down the road. What's the SOLR
: versioning scheme by the way? Is it:
that's part of the problem (and the reason why comments about the back
compat commitments for Solr have come up in this thread) ... Solr is a
young enough project that we've never made
: What should the next version of Solr be?
personally, the way the question is phrased bothers me -- it feels like
the cart leading the horse.
I think the better questions to ask are...
Q1. should we actively try to upgrade to Lucene 3.x, or should we wait
for some demonstrated
Hey Hoss,
: regular trunk structure at some point down the road. What's the SOLR
: versioning scheme by the way? Is it:
that's part of the problem (and the reason why comments about the back
compat commitments for Solr have come up in this thread) ... Solr is a
young enough project that
On Thu, Nov 19, 2009 at 3:31 PM, Yonik Seeley
yo...@lucidimagination.com wrote:
What should the next version of Solr be?
Options:
- have a Solr 1.5 with a lucene 2.9.x
- have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
of the removed lucene deprecations from 2.9-3.0
-
Yonik Seeley wrote:
What should the next version of Solr be?
Options:
- have a Solr 1.5 with a lucene 2.9.x
- have a Solr 1.5 with a lucene 3.x, with weaker back compat given all
of the removed lucene deprecations from 2.9-3.0
- have a Solr 2.0 with a lucene 3.x
-Yonik
Since Solr is dependent on Lucene I agree that there should be a major
version number bump in Solr whenever there is one in Lucene:
Solr 2.x with Lucene 3.x
On Thu, Nov 19, 2009 at 11:11 AM, Mark Miller markrmil...@gmail.com wrote:
Yonik Seeley wrote:
What should the next version of Solr be?
Gun to my head the ranking makes sense - but I don't think it has any
practical application. Plugin back compat is important and independnt
of the urls.
I think solrj back compat is important too - I can understand
experimental, but it's still important.
- Mark
Hey Yonik,
My personal experience with this is if you jump directly to 2.0, you'll have
people wondering where 1.5, 1.6--1.9 is in the CM system, and this would
create some confusion unless it is documented well. This may warrant rethinking
the tag structure a bit in SVN, or perhaps even the
Ryan McKinley wrote:
In general, I wonder where the solr back-compatibility contract
applies (and to what degree). For solr, I would rank the importance
as:
#1 - the URL API syntax. Client query parameters should change as
little as possible
#2 - configuration
#3 - java APIs
Someone
switching back to solr-dev... sorry for spinning off that thread...
What is a serious change that would warrant a bump in your opinion?
for example:
- config overhaul. detangle the XML from the components. perhaps
using
spring.
This is already done. No components read config from xml
To be clear, I am not against bumping to solr 2.0 -- I just have high
aspirations (yet little time) for what a 2.0 bump could mean for
solr.
By the way, I don't disagree with this at all - I don't think now is
the time to decide this. We don't even know what's going to happen. I
just
24 matches
Mail list logo
