It pointed to 7.1.0 for me perhaps a browser cache issue?
Anyway, you can go directly as well:
http://www.apache.org/dyn/closer.lua/lucene/solr/7.1.0
-Yonik
On Tue, Oct 17, 2017 at 11:25 AM, Susheel Kumar wrote:
> Thanks, Shalin.
>
> But the download mirror still has
On Mon, Mar 18, 2013 at 10:28 AM, Smiley, David W. dsmi...@mitre.org wrote:
Thanks Steve, and to the rest of the PMC members! I hope to see many of
you at Lucene/Solr Revolution in May.
+1
Welcome!
-Yonik
http://lucidworks.com
Congrats and welcome, Alan!
-Yonik
http://lucidworks.com
On Wed, Oct 17, 2012 at 1:36 AM, Robert Muir rcm...@gmail.com wrote:
I'm pleased to announce that the Lucene PMC has voted Alan as a
Lucene/Solr committer.
Alan has been contributing patches on various tricky stuff: positions
When sorting, ties are broken by the internal document id. This gives
us a stable (if somewhat arbitrary) sort ordering.
If you want score to be the tiebreaker, you can specify it as the
secondary sort.
-Yonik
http://www.lucene-eurocon.com - The Lucene/Solr User Conference
On Tue, Sep 6, 2011
On Tue, Sep 6, 2011 at 4:48 PM, BrianK brian.krue...@bonton.com wrote:
by internal document id you are referring to a field that is not visible to
us. We have an id field, I assume this is not the document id field you
are talking about. Assuming document id is not available to us, is it
A single merged project works only when people are relatively on the same page,
and when people feel it's mutually beneficial. Recent events make it
clear that that
is no longer the case.
Improvements to Solr have been recently blocked and reverted on the
grounds that the new functionality was
On Mon, Nov 8, 2010 at 1:02 PM, Uwe Schindler u...@thetaphi.de wrote:
Die, Contrib, die! We will hopefully only have modules soon?
+1 to Lucene Core, Lucene Modules and Solr. As qualifier we can use
for Java to differentiate from .NET. But in my opinion, all others should
be separate
For Solr, we can just move the current trunk to a 15 branch.
-Yonik
On Tue, Mar 23, 2010 at 9:39 AM, Grant Ingersoll gsing...@apache.org wrote:
On Mar 22, 2010, at 8:27 AM, Uwe Schindler wrote:
Hi all,
the discussion where to do the development after the merge, now gets actual:
Currently
On Mon, Mar 22, 2010 at 2:20 PM, Ryan McKinley ryan...@gmail.com wrote:
I'm confused... what is the need for a new name? The only place where
there is a conflict is in the top level svn tree...
Agree, no need to re-brand.
What about something general like:
On Sun, Mar 14, 2010 at 11:02 AM, Otis Gospodnetic
otis_gospodne...@yahoo.com wrote:
Would it be correct to say that a subset of Lucene/Solr committers discussed
the proposal internally/offline (i.e. not on MLs) before proposing it?
Nope. Where did this idea come from?
I'm quite sure my
On Sun, Mar 14, 2010 at 2:36 PM, Otis Gospodnetic
otis_gospodne...@yahoo.com wrote:
if I understand things correctly, poaching is only needed when the code is
not committed in the
right project/location to begin with.
That is the problem though - Solr should be allowed to keep whatever
code
On Sun, Mar 14, 2010 at 2:58 PM, Otis Gospodnetic
otis_gospodne...@yahoo.com wrote:
Would it make sense to think of Solr as one such Lucene module?
In other words, don't even bother with merging just the -dev lists, but
really just merge everything. In that case Solr's relationship with
Thanks everyone, this vote has passed.
A bit more contentious of a PMC vote than usual, but the committer
vote was clear.
-Yonik
On Mon, Mar 8, 2010 at 9:11 PM, Yonik Seeley ysee...@gmail.com wrote:
Apoligies in advance for calling yet another vote, but I just wanted
to make sure
I think the problem is political - and that leads to both technical
and political problems.
We came up with a largely political solution that should solve both.
We can't have a one way street of pulling everything interesting out
of Solr for Lucene, or poaching, or expanding Lucene's domain while
On Tue, Mar 9, 2010 at 9:48 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
I have built 10s of projects that
have simply used Lucene as an API and had no need for Solr, and I've built
10s of projects where Solr made perfect sense. So, I appreciate their
separation.
As does
On Tue, Mar 9, 2010 at 11:00 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
However, like I said it seems to be like
the discussion of the real issues is only happening recently over the past
few days.
This certainly isn't new territory for lucene/solr devs though - the
On Tue, Mar 9, 2010 at 11:35 AM, Michael Busch busch...@gmail.com wrote:
No matter if this dev-merge vote passes or not, we still
want a separate analysis module, right?
No. That's the point of the dev merge - to allow free movement of
source code that benefits both projects.
-Yonik
Apoligies in advance for calling yet another vote, but I just wanted
to make sure this was official.
Mike's second VOTE thread could probably technically stand on it's own
(since it included PMC votes), but given that I said in my previous
VOTE thread that I was just polling Lucene/Solr committers
On Mon, Mar 8, 2010 at 9:22 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
For completeness from the VOTE on private@
It's called private for a reason.
-Yonik
On Mon, Mar 8, 2010 at 9:49 PM, Michael Busch busch...@gmail.com wrote:
Question: Is it sufficient to have more +1s than -1s for this vote to pass?
3 +1s and more +1s than -1s is sufficient.
I thought for votes as significant as this one a -1 veto is a showstopper?
It's not really tied to
+1
Great idea! :-)
-Yonik
On Wed, Mar 3, 2010 at 5:42 PM, Yonik Seeley yo...@apache.org wrote:
Many Lucene/Solr committers think that merging development would be a
benefit to both projects.
Separate downloads would remain (among other things), so end users
would not be impacted (except
+1
-Yonik
On Thu, Mar 4, 2010 at 4:33 PM, Michael McCandless
luc...@mikemccandless.com wrote:
A new vote, that slightly changes proposal from last vote (adding only
that Lucene can cut a release even if Solr doesn't):
* Merging the dev lists into a single list.
* Merging committers.
*
Many Lucene/Solr committers think that merging development would be a
benefit to both projects.
Separate downloads would remain (among other things), so end users
would not be impacted (except for higher quality products over time).
Since this is a change to Lucene/Solr project development, I'd
On Wed, Mar 3, 2010 at 7:41 PM, Mark Miller markrmil...@gmail.com wrote:
I'm only for the merge with aligned releases - its the only way Solr can
really stay on Lucene trunk happily. Aligned releases are also my biggest
worry (and part of why I initially leaned against such a merge), but
On Fri, Feb 26, 2010 at 5:15 PM, Steven A Rowe sar...@syr.edu wrote:
On 02/24/2010 at 2:20 PM, Yonik Seeley wrote:
I've started to think that a merge of Solr and Lucene would be in the
best interest of both projects.
The Sorlucene :) merger could be achieved virtually, i.e. via policy, rather
I've started to think that a merge of Solr and Lucene would be in the
best interest of both projects.
Recently, Solr as pulled back from using Lucene trunk (or even the
latest version), as the increased amount of change between releases
(and in-between releases) made it impractical to deal with.
On Tue, Dec 29, 2009 at 7:13 PM, Marvin Humphrey mar...@rectangular.com wrote:
... but for this algorithm, different rasterization resolutions need not
proceed by powers-of-two.
Indeed - one way to further generalize would be to use something like
Lucene's trie-based Numeric field, but with a
On Thu, Oct 29, 2009 at 7:27 PM, Michael McCandless
luc...@mikemccandless.com wrote:
OK, let's try this again!
I've built new release artifacts from svn rev 831145 (on the 2.9
branch), here:
http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/
Changes are here:
On Thu, Oct 29, 2009 at 8:49 AM, Uwe Schindler u...@thetaphi.de wrote:
Yes, it's too bad!
But you will replace the lucene jars in the artifacts before releasing?
Because it would not be good to have jar files with version 2.9.1 in the
package that are not the officially released 2.9.1
, 2009 at 8:59 AM, Grant Ingersoll gsing...@apache.orgwrote:
Yeah, unfortunately, I think we need to use the new Jars.
On Oct 29, 2009, at 8:52 AM, Yonik Seeley wrote:
On Thu, Oct 29, 2009 at 8:49 AM, Uwe Schindler u...@thetaphi.de wrote:
Yes, it's too bad!
But you will replace the lucene
On Mon, Oct 26, 2009 at 12:43 PM, Uwe Schindler u...@thetaphi.de wrote:
Looks good. One thing:
In Mark's artifacts, he changed the common-build.xml to not have -dev in the
version before the release. You can see this in SVN. I am fine with having
-dev in the source artefact, because if
Hmmm, weren't you going to update the version numbers to 1.4.1-dev
like we just discussed in the other thread?
That way if someone changes some of the solr source from the download
and recompiles, they don't get a version number of 1.4.0
-Yonik
http://www.lucidimagination.com
On Mon, Oct 26,
On Mon, Oct 26, 2009 at 9:58 PM, Grant Ingersoll gsing...@apache.org wrote:
OK, take two is up in the same place. Please vote.
I'm seeing emptiness at
http://people.apache.org/~gsingers/solr/1.4.0/
-Yonik
http://www.lucidimagination.com
On Oct 26, 2009, at 6:15 PM, Grant Ingersoll wrote:
On Tue, Jul 14, 2009 at 4:53 PM, Uwe Schindleru...@thetaphi.de wrote:
NumericRangeQuery is not only geographical search... So it would also cover
other directions: Things I can do with Lucene additionally to full text
search, that could be done before only with RDBMS and/or PostGIS...: Do full
On Mon, Mar 24, 2008 at 9:34 PM, Otis Gospodnetic
[EMAIL PROTECTED] wrote:
Hi Yannis,
I don't think there is anything of that sort in Lucene, but this shouldn't
be hard to do with a process outside Lucene. Of course. optimizing an index
increases its size temporarily, so your external
Solr has just graduated from the Incubator, and has been accepted as a
Lucene sub-project!
Thanks to all the Lucene and Solr users, contributors, and developers
who helped make this happen!
I have a feeling we're just getting started :-)
-Yonik
On 11/9/06, ltaylor.employon [EMAIL PROTECTED] wrote:
I am currently evaluating Lucene to see if it would be appropriate to
replace my company's current search software. So far everything has been
looking great, however there is one requirement that I am not too certain
about.
What we need to
On 10/19/06, Steven Parkes [EMAIL PROTECTED] wrote:
You mention partitioning of indexes, though mostly around delete. What
about scalability of corpus size?
Definitely in scope. Solr already has scalability of search volume
via searchers behind of a load balancer all getting their index from
On 10/18/06, Doug Cutting [EMAIL PROTECTED] wrote:
Does this make sense? Does it sound like it would be useful to Solr?
To Nutch? To others? Who would be interested and able to work on it?
Rather than holding my tounge until I wrap my head around all the
issues, I'll say that I'm definitely
On 10/6/06, James [EMAIL PROTECTED] wrote:
Our indexes are, in aggregate across our
various collections, even larger than you need. We use Remote
ParalellMultiSearcher, with some custom modifications (and we are in the
process of making more)
I'm looking into adding some form of distributed
On 10/6/06, Slava Imeshev [EMAIL PROTECTED] wrote:
-- James [EMAIL PROTECTED] wrote:
If the index is broken into multiple shards then we need multiple copies
of each shard, and some way of loadbalancing and failing over amongst copies
of shards.
Yep. Unfortunately it's not simple, but
Binary fields can be stored, but not indexed.
-Yonik
Now hiring -- http://tinyurl.com/7m67g
On 9/26/05, Fredrik Andersson [EMAIL PROTECTED] wrote:
I was hoping to avoid the overhead of encoding/decoding, but it looks like
I'll have to do that :(
While on the topic, I noticed in the Field
42 matches
Mail list logo