On Mar 17, 2010, at 9:41 PM, Yonik Seeley wrote:
On Wed, Mar 17, 2010 at 9:16 PM, Grant Ingersoll gsing...@apache.org wrote:
I tend to agree w/ Hoss here. I don't think we have to be the same version
numbers and I don't think we absolutely have to do lockstep releases.
No one said
On Thu, Mar 18, 2010 at 08:50:53AM -0400, Grant Ingersoll wrote:
It's important to try and release at the same time. Without that, it
makes a lot less sense for Solr to be on Lucene's trunk.
I don't think releasing separately means Solr can't be on Lucene's trunk.
The two issues are
[
https://issues.apache.org/jira/browse/SOLR-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846891#action_12846891
]
Yonik Seeley commented on SOLR-1830:
The issue was that the writer being opened in the
[
https://issues.apache.org/jira/browse/SOLR-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-1379.
Resolution: Fixed
Fix Version/s: (was: 1.5)
3.1
Add
[
https://issues.apache.org/jira/browse/SOLR-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846896#action_12846896
]
Yonik Seeley commented on SOLR-1830:
A quick datapoint - BasicFunctionalityTest dropped
Is there any reason why CoreContainer shouldn't throw an exception if
solr.xml declares a core w/o a name, or two cores with the same name?
This makes sense. I think WAY WAY back (in a patch), cores could be
initialized by index, but that became moot with the CoreContainer
stuff.
ryan
On Thu, Mar 18, 2010 at 10:11 AM, Ryan McKinley ryan...@gmail.com wrote:
Is there any reason why CoreContainer shouldn't throw an exception if
solr.xml declares a core w/o a name, or two cores with the same name?
This makes sense. I think WAY WAY back (in a patch), cores could be
On Thu, Mar 18, 2010 at 8:20 AM, Marvin Humphrey mar...@rectangular.com wrote:
I think the concern is what happens if Solr migrates a bunch of stuff into
Lucene, ceding control over crucial functionality, and then Solr wants to
release but Lucene does not. That would pose a problem for Solr,
On Thu, Mar 18, 2010 at 11:33 AM, Michael McCandless
luc...@mikemccandless.com wrote:
On version numbering... my inclination would be to let Solr and Lucene
use their own version numbers (don't sync them up). I know it'd
simplify our lives to have the same version across the board, but
these
Ahh, OK.
Meaning Solr will have to remove deprecated support, which means
Solr's next released version would be a major release? Ie 2.0?
Mike
On Thu, Mar 18, 2010 at 11:26 AM, Robert Muir rcm...@gmail.com wrote:
On Thu, Mar 18, 2010 at 11:33 AM, Michael McCandless
luc...@mikemccandless.com
Alight, so we have implemented Hoss' suggestion here on the lucene/solr
merged dev branch at lucene/solr/branches/newtrunk.
Feel free to check it out and give some feedback.
We also roughly have Solr running on Lucene trunk - eg compiling Solr
will first compile lucene and run off those
On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Ahh, OK.
Meaning Solr will have to remove deprecated support, which means
Solr's next released version would be a major release? Ie 2.0?
I've been working on the assumption of 3.1 - matching Lucene.
Solr
All tests pass for me :)
Mike
On Thu, Mar 18, 2010 at 12:27 PM, Mark Miller markrmil...@gmail.com wrote:
Alight, so we have implemented Hoss' suggestion here on the lucene/solr
merged dev branch at lucene/solr/branches/newtrunk.
Feel free to check it out and give some feedback.
We also
: As you stated modules were important to think about for svn location,
: then it would only make sense that they are important to think about
: for release numbering, too.
I don't think svn location should neccessarily influence release
numbering, but release bundling certianly should.
if we
On Thu, Mar 18, 2010 at 2:01 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
I thinks solr-3.1 only makes sense if Solr is include in one big
giant apache-lucene-3.1.tgz release
Projects have multiple artifacts all the time for user convenience.
Binary vs source downloads, different subsets
On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Ahh, OK.
Meaning Solr will have to remove deprecated support, which means
Solr's next released version would be a major release? Ie 2.0?
Its more complex than this. Solr depends on some lucene contrib
: I thinks solr-3.1 only makes sense if Solr is include in one big
: giant apache-lucene-3.1.tgz release
:
: Projects have multiple artifacts all the time for user convenience.
Ugh ... sorry, poor phrasing on my part ... i was not suggesting that we
*should* have a single monolithic release
: In the two cores with one name scenario, presumably you meant to name
: one something different. You try to access the core under that
: different name, get a core-not-found and go look at the solr.xml to
: see why. Same scenario.
:
: So while I don't see extra code as necessary for that
On Thu, Mar 18, 2010 at 2:16 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
3.1 may make life easy for us as developers, but is likely to be just as
cofusing to users as if we called the next version Q
We're jumping to version 3.1 because we're releasing at the same time,
and are based on
On Mar 18, 2010, at 2:06 PM, Robert Muir wrote:
On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Ahh, OK.
Meaning Solr will have to remove deprecated support, which means
Solr's next released version would be a major release? Ie 2.0?
But we need
: We're jumping to version 3.1 because we're releasing at the same time,
: and are based on Lucene 3.1.
You say it like it's a done deal, but I don't get the impression
that i'm the only one who thinks it's unneccessary.
My point is really simple: Even if we release at the same time, and
On Thu, Mar 18, 2010 at 2:36 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: We're jumping to version 3.1 because we're releasing at the same time,
: and are based on Lucene 3.1.
You say it like it's a done deal, but I don't get the impression
that i'm the only one who thinks it's
: Sorry - I should have quoted it.
: You cited user confusion, and I was giving an example of how it was
: very easy to explain... an example of what I'd put in the release
: notes to explain it.
Ahhh... sorry, yes i did in fact missunderstand that part.
: Jumping major releases is a really
On Thu, Mar 18, 2010 at 2:49 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
Use 3.1 and developers in the know will understand that i's because we're
using LuceneJava 3.1; but uninformed users *might* be confused as to why
it jumped to a (seemingly) arbitrary number.
I also like to look
On 03/18/2010 02:49 PM, Chris Hostetter wrote:
Use 3.1 and developers in the know will understand that i's because we're
using LuceneJava 3.1; but uninformed users *might* be confused as to why
it jumped to a (seemingly) arbitrary number.
Sorry about the following non serious reply:
It
On 3/18/10 11:25 AM, Yonik Seeley ysee...@gmail.com wrote:
On Thu, Mar 18, 2010 at 2:16 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
3.1 may make life easy for us as developers, but is likely to be just as
cofusing to users as if we called the next version Q
We're jumping to version
: We're jumping to version 3.1 because we're releasing at the same time,
: and are based on Lucene 3.1.
You say it like it's a done deal, but I don't get the impression
that i'm the only one who thinks it's unneccessary.
+1, I'm right there with you on this Hoss.
My point is really
Hmmm... may be I am completely wrong but let's take JBoss. It ships products
based on community driven projects but I am not aware of the fact that they
would try to affect community wrt to numbering or repositories merges. It is
up to JBoss developers and testers to deal with this complexity and
On Mar 18, 2010, at 2:49 PM, Chris Hostetter wrote:
: Sorry - I should have quoted it.
: You cited user confusion, and I was giving an example of how it was
: very easy to explain... an example of what I'd put in the release
: notes to explain it.
Ahhh... sorry, yes i did in fact
[
https://issues.apache.org/jira/browse/SOLR-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-1823.
Resolution: Fixed
Fix Version/s: 1.5
Assignee: Hoss Man
Nice catch Frank.
FWIW: the
Hello,
Can I submit bug fixes? If so, what is the procedure?
Thanks,
Sanjoy
DataImportHandler not escaping single quotes
Key: SOLR-1831
URL: https://issues.apache.org/jira/browse/SOLR-1831
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
[
https://issues.apache.org/jira/browse/SOLR-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin updated SOLR-1831:
Environment:
Windows XP Pro SP3
java 1.6.0.18
Solr 1.4 and Solr 1.5-dev using example-DIH and example start.jar
[
https://issues.apache.org/jira/browse/SOLR-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847166#action_12847166
]
Hoss Man commented on SOLR-1824:
Scratch that -- i get it now:
* IndexSchem uses anonymous
abortOnConfigurationError=false no longer works for most plugin types
-
Key: SOLR-1832
URL: https://issues.apache.org/jira/browse/SOLR-1832
Project: Solr
Issue Type: Bug
[
https://issues.apache.org/jira/browse/SOLR-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847170#action_12847170
]
Hoss Man commented on SOLR-1832:
This seems to be a result of switching away from the
On Thu, Mar 18, 2010 at 6:49 PM, Sanjoy Ghosh san...@yahoo.com wrote:
Hello,
Can I submit bug fixes? If so, what is the procedure?
Thanks,
Sanjoy
Hello,
Please take a look at this link: http://wiki.apache.org/solr/HowToContribute
--
Robert Muir
rcm...@gmail.com
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847174#action_12847174
]
Hoss Man commented on SOLR-1817:
I started looking a little more closely at the singleton
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847175#action_12847175
]
Yonik Seeley commented on SOLR-1817:
bq. I'm starting to think the whole idea of
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847177#action_12847177
]
Hoss Man commented on SOLR-1817:
Tangential Comment...
If we *do* decide that it's worth
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847176#action_12847176
]
Mark Miller commented on SOLR-1817:
---
bq. Maybe we should just kill the whole concept, and
: Sorry about the following non serious reply:
:
: It hasn't seemed to hurt the most popular software in the world to be way
: worse than that ;)
:
: 1, 2, 3, NT, 95, 98, 98SE, ME, CE, 2000, XP, 2003, Vista, 2008, 7 (by who's
a) 2000 came out before ME
b) NT, CE, and 2003 (a server edition)
On 03/18/2010 09:27 PM, Chris Hostetter wrote:
: Sorry about the following non serious reply:
:
: It hasn't seemed to hurt the most popular software in the world to be way
: worse than that ;)
:
: 1, 2, 3, NT, 95, 98, 98SE, ME, CE, 2000, XP, 2003, Vista, 2008, 7 (by who's
a) 2000 came out
: Sorry about the following non serious reply:
:
: It hasn't seemed to hurt the most popular software in the world to be way
: worse than that ;)
:
: 1, 2, 3, NT, 95, 98, 98SE, ME, CE, 2000, XP, 2003, Vista, 2008, 7 (by who's
a) 2000 came out before ME
b) NT, CE, and 2003 (a server
[
https://issues.apache.org/jira/browse/SOLR-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-1811.
--
Resolution: Fixed
committed r925091
Thanks Sean
DataImportHandler: dataimporter.functions.formatDate
45 matches
Mail list logo
