I don't see a compelling reason to go to 3.1. It is going to be very
confusing for users (when did 3.0 come out? Did I miss it?) At least
when MS Word jumped from 2.0 to 6.0 it wasn't to a minor version (i.e.
6.1). 2.0 seems reasonable, as does 1.5. Although 2.0 would be a good
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
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
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
: 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
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
: 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
: No, actaully it's the converse issue -- if a major piece moves from solr
: to core and a *person* wanted to make a major change to that piece of
: functionality that wasn't backwards compatible, then core would
: certianly need to undergo a major version bump.
:
: To try and put it simply
On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: No, actaully it's the converse issue -- if a major piece moves from solr
: to core and a *person* wanted to make a major change to that piece of
: functionality that wasn't backwards compatible, then core
: In the interest of moving forward, perhaps we should just focus on the
: immediate next major release - 3.1. What happens after can wait. We
: never planned for absolutely all the what if's in Solr before the
: merge - I'm not sure why we would need to now.
I suppose, but if we call the next
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.
On Mar 17, 2010, at 8:38 PM, Chris Hostetter wrote:
: In the interest of moving forward, perhaps we should just focus on the
: immediate next
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 absolutely.
It's important to try and release at the same
Hi All,
: In the interest of moving forward, perhaps we should just focus on the
: immediate next major release - 3.1. What happens after can wait. We
: never planned for absolutely all the what if's in Solr before the
: merge - I'm not sure why we would need to now.
I suppose, but
On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
My key point being: Version numbers should communicate the
significance in change to the *user* of the product, and the users of
Solr are differnet then the users of Lucene-Java, so even if the releases
happen in
Here is a very rough list of what makes sense to me:
- since lucene is on a new major version, the next solr release
containing that sould have a new major version number
- this does not preclude further releases on 1.x
- for simplicity, and the single dev model, we should just sync
with
another minor addition:
- move to Junti4 for new tests... and some old tests might be
migrated (for speed issues)
I already have a SolrTestCaseJ4 that extends LuceneTestCase4J that
avoids spinning up a solr core for each test method... but I need to
be able to reference LuceneTestCase4J from
On Mar 16, 2010, at 11:00 AM, Yonik Seeley wrote:
Here is a very rough list of what makes sense to me:
- since lucene is on a new major version, the next solr release
containing that sould have a new major version number
- this does not preclude further releases on 1.x
- for simplicity,
On Tue, Mar 16, 2010 at 10:45 AM, Grant Ingersoll gsing...@apache.org wrote:
On Mar 16, 2010, at 11:00 AM, Yonik Seeley wrote:
Here is a very rough list of what makes sense to me:
- since lucene is on a new major version, the next solr release
containing that sould have a new major version
One more addition:
- Consider a different wiki... our current style will serve us poorly
across major version bumps esp. We need versioning. A different
option could include moving more documentation onto the website, where
it would be versioned. Getting something easy to edit/change would be
+1 on moving to Java 6 since Java 5 has been EOL'ed.
Bill
On Tue, Mar 16, 2010 at 12:00 PM, Yonik Seeley yo...@apache.org wrote:
One more addition:
- Consider a different wiki... our current style will serve us poorly
across major version bumps esp. We need versioning. A different
: - since lucene is on a new major version, the next solr release
: containing that sould have a new major version number
This rationale concerns me less then making sure the version change
adequately communicates the significance of upgrading' to users ... ie:
if most/many users will need to
could actually
result in very little change for the Solr end user.
-Kevin
From: Chris Hostetter hossman_luc...@fucit.org
To: solr-dev@lucene.apache.org
Sent: Tue, March 16, 2010 10:47:53 AM
Subject: Re: rough outline of where Solr's going
: - since lucene
The key word here is end-user.
On Tue, Mar 16, 2010 at 10:57 AM, Kevin Osborn osbo...@yahoo.com wrote:
I definitely agree with Chris here. Although Lucene and Solr are highly
related, the version numbering should communicate whether Solr has changed
in a significant or minor way to the
On Tue, Mar 16, 2010 at 1:47 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
even if we get Lucene-Java and Solr onto the same
scheme now, we could easily find ourselves in a situation where
we're ready to release lucene-3.3 (ie: a minor release that is
back-compat with lucene-3.2 and
: We try not to do that then. Things make a lot more sense when one
: starts thinking of them as a single project, w/o multiple downloads.
:
: If major modules were to be pulled from Solr and put into Lucene, and
: Solr wanted to make some big changes for a major version number bump?
: How
On Tue, Mar 16, 2010 at 2:25 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: We try not to do that then. Things make a lot more sense when one
: starts thinking of them as a single project, w/o multiple downloads.
:
: If major modules were to be pulled from Solr and put into Lucene,
44 matches
Mail list logo
