Re: rough outline of where Solr's going

2010-03-21 Thread Ryan McKinley

 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 
 reason to get rid of deprecations.


I agree.  2.0 or 1.5 makes the most sense.

(In the past I suggested we may not be at 2.0 yet... but with all the
internal re-jiggering, I now think 2.0 would be best).

Locking the solr major number to lucene major number does not make any
sense to me.  Say there were a major change to solr (for argument
sake, perhaps it gets in bed with spring), but there is no major
change in lucene...  then what?


Re: rough outline of where Solr's going

2010-03-18 Thread Grant Ingersoll

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 absolutely.
 
 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 orthogonal.

 Many of us
 believe this is important to try to do... so I guess we'll try to do
 that, even if everyone isn't on board.

I agree, it's important to try, but it isn't a show stopper, which is what the 
word lockstep implies.

Re: rough outline of where Solr's going

2010-03-18 Thread Marvin Humphrey
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 orthogonal.

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, no?  

In which case Solr might have been better off not having merged and
maintaining the status quo with all of its code duplication problems, etc.

Marvin Humphrey


Re: rough outline of where Solr's going

2010-03-18 Thread Michael McCandless
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, no?

But, I don't think we'd ever do this -- ie when we release Solr we'll
also release Lucene.

Think about it... if for some exotic reason Lucene is unreleasable,
then, presumably we would not up and release Solr until we fixed
whatever was broken with Lucene, since it'd also break Solr.

It is conceivable we could release only Lucene (yes, this was an
explicit part of the vote, take 2), but I expect in practice that'll be
the exception not the rule... it remains to be seen.

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 numbers are really for our users, telling them when big changes
were made, back compat broken, etc.  I think that trumps dev
convenience.

Mike


Re: rough outline of where Solr's going

2010-03-18 Thread Robert Muir
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 numbers are really for our users, telling them when big changes
 were made, back compat broken, etc.  I think that trumps dev
 convenience.

Be sure to consider the deprecations removal, its not possible for
Solr to move to Lucene's trunk without this.

Here are two examples of necessary deprecation removals in the branch
so that Solr can use Lucene's trunk:
https://issues.apache.org/jira/browse/SOLR-1820
http://www.lucidimagination.com/search/document/f07da8e4d69f5bfe/removal_of_deprecated_htmlstrip_tokenizer_factories

It seems to be the consensus that people want a major version change
number when this is done.

So this is an example where the version numbers of Solr really do
relate to Lucene, if we want them to share the same trunk.


-- 
Robert Muir
rcm...@gmail.com


Re: rough outline of where Solr's going

2010-03-18 Thread Michael McCandless
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 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 numbers are really for our users, telling them when big changes
 were made, back compat broken, etc.  I think that trumps dev
 convenience.

 Be sure to consider the deprecations removal, its not possible for
 Solr to move to Lucene's trunk without this.

 Here are two examples of necessary deprecation removals in the branch
 so that Solr can use Lucene's trunk:
 https://issues.apache.org/jira/browse/SOLR-1820
 http://www.lucidimagination.com/search/document/f07da8e4d69f5bfe/removal_of_deprecated_htmlstrip_tokenizer_factories

 It seems to be the consensus that people want a major version change
 number when this is done.

 So this is an example where the version numbers of Solr really do
 relate to Lucene, if we want them to share the same trunk.


 --
 Robert Muir
 rcm...@gmail.com



Re: rough outline of where Solr's going

2010-03-18 Thread Yonik Seeley
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 exposes Lucene both indirectly and directly - matching the
version can be very meaningful to the end user.

Will it work forever?  I don't know - but Lucene has only had 2 bumps
in it's whole life, and solr has had none so far.  These seem to be
rare events.  And if it becomes necessary to bump Solr's major w/o
Lucene in the future... well, so be it.  It will be a major version
bump - so people will have to read to understand what has changed
anyway.


-Yonik


Re: rough outline of where Solr's going

2010-03-18 Thread Chris Hostetter

: 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 release lucene-java-X.Y.tgz and lucene-solr-N.M.tgz on the same 
day from the same trunk, and lucene-java-X.Y.tgz contains multiple 
somewhat independent modules/contribs then they should all certainly have 
the same version number (X.Y) -- but i don't think that neccessarily means 
that X.Y needs to equal N.M.

: So lets say we spin off a lucene-analyzers module, it should be 3.1,
: too, as its already a module to some degree, and having a
: lucene-analyzers-1.0.jar would be downright misleading.

I was never suggesting that any version numbers should go backwards and 
reset to 1.0 ... if the only way to get lucene-analyzers-X.Y.jar right now 
is part of lucene-java-X.Y.tgz then they should have identicle version 
numbers.  if we then spin off lucene-analyzers so that 
lucene-analyzers-A.B.jar is now released as it's own artifact 
(lucene-analyzers-A.B.tgz) then A.B should be whatever makes sense as an 
increment from the previously released version of lucene-analyzers.

Concretely: if lucene-java-3.5.tgz contains lucene-core-3.5.jar and 
(lucene-analyzers-3.5.jar, and then we decide that we want to start 
releasing lucene-analyzers.jar independently of lucene-java, then the 
rlease should produce *either* lucene-analyzers-3.6.tgz or 
lucene-analyzers-4.0.tgz -- depending on how significant the changes in 
API/functionality are for the users.  This should can be an independ 
decision from wether the next version lucene-java (possible/probably 
released on the same day) is lucene-java-3.6.tgz or lucene-java-4.0.tgz

: So from this perspective of modules, with solr being a module
: alongside lucene, 3.1 makes a lot of sense, and it also makes sense to
: try to release things together if possible so that users aren't
: confused.

I thinks solr-3.1 only makes sense if Solr is include in one big 
giant apache-lucene-3.1.tgz release ... if apache-solr is a seperate 
release artifact then there is no reason to try and unify the version 
numbers (that seems far more confusing to typical users of Solr, who are 
no more worried about the lucene-java version bump in solr then they are 
about the tika version bump, or any other dependency)

-Hoss



Re: rough outline of where Solr's going

2010-03-18 Thread Yonik Seeley
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 of stuff (look at Spring).

-Yonik


Re: rough outline of where Solr's going

2010-03-18 Thread Robert Muir
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
modules, which apparently have no backwards-compatibility policy.

I don't think we want to have to suddenly treat all these contrib
modules like core lucene with regards to backwards compat, some of
them haven't reached that level of maturity yet.

On the other hand, exposing contrib's functionality via Solr is a
great way to get more real users and devs giving feedback and
improvements to help them mature.

But we need to work on how to handle some of this: I suppose spatial
is the worst case (don't really know), where Solr has a dependency on
a Lucene contrib specifically labelled as experimental.

-- 
Robert Muir
rcm...@gmail.com


Re: rough outline of where Solr's going

2010-03-18 Thread Chris Hostetter

:  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 artifcat, i'm saying that since 
we are not planning on having a monolithic release artifact, we don't 
really have a need for unified version numbers -- we should try to stick 
with teh current version number sequencing for consistency to our users.

The typical solr user shouldn't have to know/care that develpment is now 
uified beween solr and the core of lucene -- the version numbers should 
bump only as appropriate to signify thelevel of change from the *users* 
perspective ... with 1.4 as the last release, it seems like the next 
logical next bumps would be 1.4.1,1.5, or 2.0

1.4.1 would imply really small amounts of changes, so that doesnt' really 
apply; 1.5 would imply similar impacts on the user as between 1.3 and 1.4, 
which also doesn't apply since we're removing deprecations and a lot of 
users will *have* to change their configs; that leaves 2.0 which is a big 
enough bump to properly convey lots of stuff has changed, pay attention

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



-Hoss



Re: rough outline of where Solr's going

2010-03-18 Thread Yonik Seeley
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 Lucene 3.1.

Not hard to understand, and it's for users too.

-Yonik


Re: rough outline of where Solr's going

2010-03-18 Thread Grant Ingersoll

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 to work on how to handle some of this: I suppose spatial
 is the worst case (don't really know), where Solr has a dependency on
 a Lucene contrib specifically labelled as experimental.

FWIW, that dependency is very minimal for this exact reason.  Plus, most of 
spatial in Solr is exposed through function queries, etc.

Re: rough outline of where Solr's going

2010-03-18 Thread Chris Hostetter

: 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 even 
if we're using Lucene-Java 3.1, that doesn't mean the solr release artifact 
*needs* to be called solr-3.1.   

the only pro i've seen suggested (over and over) is that it makes the 
solr version number consistent with the luene-java version -- but the 
con is that it's inconsistent with past versions of solr.  Since more 
Solr users (should) have never known nor cared about the lucene-Java 
version used under the hood, being consistent with past solr versioning 
seems more useful then being consistent with the versioning of something 
internal.  

hardcore users who are writing really low level plugins and interacting 
directly with the LUcnee-Java APIs inside Solr will care what 
version of LUcene-java is being used under the covers, but hey can get 
that from the release notes, it doesn't need to be advertised in the 
artifact name (2.0 will significantly advertise this is a big change, 
plugins will break)

I just don't see how jumping to solr-3.1 is any more useful to the users 
then jumping to solr-2.0; it certinaly seems more confusing.

-Hoss



Re: rough outline of where Solr's going

2010-03-18 Thread Yonik Seeley
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 unneccessary.

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.

Jumping major releases is a really big, uncompatible deal anyway - it
seems like user confusion is a really big stretch.

-Yonik


Re: rough outline of where Solr's going

2010-03-18 Thread Chris Hostetter

: 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 big, uncompatible deal anyway - it
: seems like user confusion is a really big stretch.

It may be ... but it just seems like such a no brainer easy thing to avoid 
at such little cost: 

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.

Use 2.0 and even the most uninformed user should get that this is a 
major upgrade; developers will *still* know that we're using LUcene-java 
3.1.



-Hoss



Re: rough outline of where Solr's going

2010-03-18 Thread Yonik Seeley
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 at the downside of the specific user confusion.
Their first reaction could be 3.1, what the heck is that about!   Of
course, looking at the README or CHANGES or the release announcement,
or at pretty much anything would immediately give them the answer.

Look at what happens when other software packages do a big jump in
their versioning... the reaction is sometimes that's silly or ah,
the marketing department, because there's no apparent reason for it.
At least here there is a reason.

-Yonik


Re: rough outline of where Solr's going

2010-03-18 Thread Mark Miller

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 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 count in what manner?).


--
- Mark

http://www.lucidimagination.com





Re: rough outline of where Solr's going

2010-03-18 Thread Mattmann, Chris A (388J)
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 3.1 because we're releasing at the same time,
 and are based on Lucene 3.1.

To me this is just another example of these artifacts really needing to be
kept separate.

To take the extreme case in this, then why not sync up release #s with other
major dependencies as well? Solr supports a version of the Servlet spec
right? Why not sync with that? One could argue that Solr is just as
dependent on the HTTP layer as it is on the underlying search framework?

I don't think that the release versions need to be in sync.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.mattm...@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++




Re: rough outline of where Solr's going

2010-03-18 Thread Mattmann, Chris A (388J)
 
 : 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 simple: Even if we release at the same time, and even
 if we're using Lucene-Java 3.1, that doesn't mean the solr release artifact
 *needs* to be called solr-3.1.
 
 the only pro i've seen suggested (over and over) is that it makes the
 solr version number consistent with the luene-java version -- but the
 con is that it's inconsistent with past versions of solr.

Exactly.

 Since more
 Solr users (should) have never known nor cared about the lucene-Java
 version used under the hood, being consistent with past solr versioning
 seems more useful then being consistent with the versioning of something
 internal. 

Agreed.

 
 hardcore users who are writing really low level plugins and interacting
 directly with the LUcnee-Java APIs inside Solr will care what
 version of LUcene-java is being used under the covers, but hey can get
 that from the release notes, it doesn't need to be advertised in the
 artifact name (2.0 will significantly advertise this is a big change,
 plugins will break)
 
 I just don't see how jumping to solr-3.1 is any more useful to the users
 then jumping to solr-2.0; it certinaly seems more confusing.

+1 on that.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.mattm...@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++




Re: rough outline of where Solr's going

2010-03-18 Thread Lukáš Vlček
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
deliver commercial product and explain customers what is in.

Just my 2 cents (probably not related to this discussion at all - I hope).
Lukas

On Thu, Mar 18, 2010 at 7:59 PM, Mark Miller markrmil...@gmail.com wrote:

 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 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
 count in what manner?).

 --
 - Mark

 http://www.lucidimagination.com






Re: rough outline of where Solr's going

2010-03-18 Thread Grant Ingersoll

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 missunderstand that part.
 
 : Jumping major releases is a really big, uncompatible deal anyway - it
 : seems like user confusion is a really big stretch.
 
 It may be ... but it just seems like such a no brainer easy thing to avoid 
 at such little cost: 
 
 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.
 
 Use 2.0 and even the most uninformed user should get that this is a 
 major upgrade; developers will *still* know that we're using LUcene-java 
 3.1.
 

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 reason to get rid of 
deprecations.  

-Grant

Re: rough outline of where Solr's going

2010-03-18 Thread Chris Hostetter

: 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) were all forks designed for 
differnet usages.

c) If you're willing to pony up enough cash to match the marketing budget 
spent for *any* one of those version schema transitions then I will 
happily back you up on naming the version any-freaking-thing you want.  
I'll seriously vote to call it Apache Solr Miller Edition if you pay for 
the billboards



-Hoss



Re: rough outline of where Solr's going

2010-03-18 Thread Mark Miller

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 before ME

b) NT, CE, and 2003 (a server edition) were all forks designed for
differnet usages.

c) If you're willing to pony up enough cash to match the marketing budget
spent for *any* one of those version schema transitions then I will
happily back you up on naming the version any-freaking-thing you want.
I'll seriously vote to call it Apache Solr Miller Edition if you pay for
the billboards



-Hoss

   


Heh - I knew some of that ordering was off - I basically just listed 
from memory - I don't have a clue when CE was born. Its not as simple as 
just forks though - eventually NT merged with the consumer line in XP, 
and 2003, 2008 also came from NT. These forks cross lines, so who is to 
say which way you count the versions :) And I missed 2000 server.


Seriously though, I'm not concerned with what the next version of Solr 
will be - I'm sure you guys will work it out, and I'm sure the users 
will figure it out. Me, I don't care - though I would like to remove 
deprecations.


--
- Mark

http://www.lucidimagination.com





Re: rough outline of where Solr's going

2010-03-18 Thread Mattmann, Chris A (388J)
 
 
 : 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) were all forks designed for
 differnet usages.
 
 c) If you're willing to pony up enough cash to match the marketing budget
 spent for *any* one of those version schema transitions then I will
 happily back you up on naming the version any-freaking-thing you want.
 I'll seriously vote to call it Apache Solr Miller Edition if you pay for
 the billboards

+1 to that!!

echo Miller Time.

Cheers,
Chris


++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.mattm...@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++




Re: rough outline of where Solr's going

2010-03-17 Thread Chris Hostetter

:  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 - w/o an attempt at synchronized releases,
: I'm against of code/modules moving out of solr.  It get's to the heart
: of why we merged in the first place.

Hmmm, i'm not sure what to say about that.  My recollection of the 
discussion was that almost everyone agreed that refactoring and reducing 
code overlap was a good idea, but synchronized releases seemed to be the 
biggest sticking point people had (isn't that why there was a second (or 
maybe third?) take on the vote ... to remove that item?)

In any case: it's still orthogonal to the point i'm trying to make
 
Even if Lucene-Java, and Solr, and a bunch of new modules refactored out 
of the two, all start getting lock step releases, the version labels we 
put on those releasees shouldn't neccessarily be identical.

We could easily find ourselves in either of the following two situations 
for any arbitrary release off the trunk (assume it's 2011-05-23, and the 
last release of both Lucene-Java and Solr was known as version 4.2) 

1) Lucene-Java has made some massive public API changes that included 
removing some deprecated APIs because they were horribly broken and 
could corrupt data - so people agree that the version number should be 
bumped to 5.0; Solr has never used the old buggy API, and does not 
expose any of the new underlying API changes, and has had very few changes 
since 4.2 ... reving up to 5.0 would give users the impression that 
something significant had changed, when in fact very little has changed.

2) Solr has made some major front end API changes and removed some 
deprecated RequestHandlers that were buggy, so Solr really needs to bump 
the version number up to 5.0; Lucene-Java has made some very minor 
feature additions, and the trunk is 100% back compat with 4.2 -- calling 
it lucene-Java 5.0 would give people a missleading ipression that it was 
not API compatible with the previous release.


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 lock step, that doesn't mean the verion numbers should be in 
lock step.

-Hoss



Re: rough outline of where Solr's going

2010-03-17 Thread Yonik Seeley
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 would
 :  certianly need to undergo a major version bump.
 :
 : To try and put it simply - w/o an attempt at synchronized releases,
 : I'm against of code/modules moving out of solr.  It get's to the heart
 : of why we merged in the first place.

 Hmmm, i'm not sure what to say about that.  My recollection of the
 discussion was that almost everyone agreed that refactoring and reducing
 code overlap was a good idea, but synchronized releases seemed to be the
 biggest sticking point people had (isn't that why there was a second (or
 maybe third?) take on the vote ... to remove that item?)

Most people were on board with synchronized releases.
Some people were treating it like a hard'n'fast contract forever... so
Mike added a second vote that added an out to address that:
 * Release details will be decided by dev community, but, Lucene may
  release without Solr.

The meaning, which most of us took (and expressed in the first vote
thread), that the idea was that we would try to release at the same
time, but lucene could still release if solr was clearly not ready.
It certainly wouldn't be the norm though.

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.

-Yonik


Re: rough outline of where Solr's going

2010-03-17 Thread Chris Hostetter

: 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 solr release Solr 3.1 it will set a 
precedent that will likely be impossible to maintain in a sane manner.


-Hoss



Re: rough outline of where Solr's going

2010-03-17 Thread Grant Ingersoll
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 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 solr release Solr 3.1 it will set a 
 precedent that will likely be impossible to maintain in a sane manner.
 
 
 -Hoss
 




Re: rough outline of where Solr's going

2010-03-17 Thread Yonik Seeley
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 time.  Without that, it
makes a lot less sense for Solr to be on Lucene's trunk.  Many of us
believe this is important to try to do... so I guess we'll try to do
that, even if everyone isn't on board.

-Yonik


Re: rough outline of where Solr's going

2010-03-17 Thread Mattmann, Chris A (388J)
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 if we call the next solr release Solr 3.1 it will set a
 precedent that will likely be impossible to maintain in a sane manner.
 

+1. Release versions should make sense.

The next release of Solr, if it's a major version increment (anecdotally
which should have technical justification for being so -- not saying it
doesn't, but would be good to say why the major version increment is
necessary), should be +1.0 on the current major version number, which is 1.x
+ 1.0 = 2.x.

I'd ask the question what happened to 1.5, or 1.6 (or anywhere in-between),
but that's another question.

Here's the link to the thread where we talked about this before:

http://www.mail-archive.com/solr-dev@lucene.apache.org/msg21936.html

I guess what I'm saying is that 2.0 is a lot better than 3.2 (and [here's
where my opinion comes in] 1.5 isn't so bad either).

Cheers,
Chris



++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.mattm...@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++




Re: rough outline of where Solr's going

2010-03-17 Thread Robert Muir
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 lock step, that doesn't mean the verion numbers should be in
 lock step.


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.

So lets say we spin off a lucene-analyzers module, it should be 3.1,
too, as its already a module to some degree, and having a
lucene-analyzers-1.0.jar would be downright misleading.

So from this perspective of modules, with solr being a module
alongside lucene, 3.1 makes a lot of sense, and it also makes sense to
try to release things together if possible so that users aren't
confused.


-- 
Robert Muir
rcm...@gmail.com


Re: rough outline of where Solr's going

2010-03-16 Thread Yonik Seeley
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 the lucene sources (i.e it
works in the IDE, but not on the command line right now).

-Yonik




On Tue, Mar 16, 2010 at 10:00 AM, Yonik Seeley yo...@apache.org 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, and the single dev model, we should just sync
 with lucene's... i.e. the next major Solr version would be 3.1
 - branches/solr would become the new trunk, with a shared trunk with
 lucene in some structure (see other thread)
 - solr cloud branch gets merged in
 - we move to Java6 (Java5 has already been EOLd by Sun unless you pay
 money... and we need Java6 for zookeeper, scripting)
 - remove deprecations (finally!), and perhaps some additional cleanups
 that we've wanted to do

 -Yonik



Re: rough outline of where Solr's going

2010-03-16 Thread Grant Ingersoll

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, and the single dev model, we should just sync
 with lucene's... i.e. the next major Solr version would be 3.1
 - branches/solr would become the new trunk, with a shared trunk with
 lucene in some structure (see other thread)
 - solr cloud branch gets merged in
 - we move to Java6 (Java5 has already been EOLd by Sun unless you pay
 money... and we need Java6 for zookeeper, scripting)

Hmm, how does that effect Lucene, though?  It is only on 1.5.

-Grant


Re: rough outline of where Solr's going

2010-03-16 Thread Yonik Seeley
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 number
  - this does not preclude further releases on 1.x
  - for simplicity, and the single dev model, we should just sync
 with lucene's... i.e. the next major Solr version would be 3.1
 - branches/solr would become the new trunk, with a shared trunk with
 lucene in some structure (see other thread)
 - solr cloud branch gets merged in
 - we move to Java6 (Java5 has already been EOLd by Sun unless you pay
 money... and we need Java6 for zookeeper, scripting)

 Hmm, how does that effect Lucene, though?  It is only on 1.5.

Same way it did when lucene core was 1.4 but some of the contribs were 1.5
i.e. I don't think it really should affect anything.  Lucene core
moving to 1.5 is a different decision.

-Yonik


Re: rough outline of where Solr's going

2010-03-16 Thread Yonik Seeley
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
the key there we don't have that currently.

-Yonik


On Tue, Mar 16, 2010 at 10:06 AM, Yonik Seeley yo...@apache.org wrote:
 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 the lucene sources (i.e it
 works in the IDE, but not on the command line right now).

 -Yonik




 On Tue, Mar 16, 2010 at 10:00 AM, Yonik Seeley yo...@apache.org 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, and the single dev model, we should just sync
 with lucene's... i.e. the next major Solr version would be 3.1
 - branches/solr would become the new trunk, with a shared trunk with
 lucene in some structure (see other thread)
 - solr cloud branch gets merged in
 - we move to Java6 (Java5 has already been EOLd by Sun unless you pay
 money... and we need Java6 for zookeeper, scripting)
 - remove deprecations (finally!), and perhaps some additional cleanups
 that we've wanted to do

 -Yonik




Re: rough outline of where Solr's going

2010-03-16 Thread Bill Au
+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
 option could include moving more documentation onto the website, where
 it would be versioned.  Getting something easy to edit/change would be
 the key there we don't have that currently.

 -Yonik


 On Tue, Mar 16, 2010 at 10:06 AM, Yonik Seeley yo...@apache.org wrote:
  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 the lucene sources (i.e it
  works in the IDE, but not on the command line right now).
 
  -Yonik
 
 
 
 
  On Tue, Mar 16, 2010 at 10:00 AM, Yonik Seeley yo...@apache.org 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, and the single dev model, we should just sync
  with lucene's... i.e. the next major Solr version would be 3.1
  - branches/solr would become the new trunk, with a shared trunk with
  lucene in some structure (see other thread)
  - solr cloud branch gets merged in
  - we move to Java6 (Java5 has already been EOLd by Sun unless you pay
  money... and we need Java6 for zookeeper, scripting)
  - remove deprecations (finally!), and perhaps some additional cleanups
  that we've wanted to do
 
  -Yonik
 
 



Re: rough outline of where Solr's going

2010-03-16 Thread Chris Hostetter

: - 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 make config changes in order to upgrade, 
that seems like a major upgrade to me, and the version number should 
change in a major way ... if that means 2.0, 3.0, 10.0, or 3.1 i don't 
care.

:   - for simplicity, and the single dev model, we should just sync
: with lucene's... i.e. the next major Solr version would be 3.1

this concerns me a little in that it doesn't feel like we've really 
talked through how exactly we expect the version number game to play out 
over time ... 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 addss some new features) but we also want 
to release a new major version of solr that breaks compatibility with 
solr-3.2 ... so what do we call that?

in short: trying to sync version numbers seems like a pain with very 
little beenfit -- version numbers should communicate significance of 
change, not dependency information.

: - remove deprecations (finally!), and perhaps some additional cleanups
: that we've wanted to do

As long as we bump the major version number to communicate the 
significance, i'm all in favor of purging deprecations anytime people 
want.


-Hoss



Re: rough outline of where Solr's going

2010-03-16 Thread Kevin Osborn
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 end-user. A minor change in Lucene could cause 
major changes in Solr. And vice-versa, a major change in Lucene 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 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 make config changes in order to upgrade, 
that seems like a major upgrade to me, and the version number should 
change in a major way ... if that means 2.0, 3.0, 10.0, or 3.1 i don't 
care.

:   - for simplicity, and the single dev model, we should just sync
: with lucene's... i.e. the next major Solr version would be 3.1

this concerns me a little in that it doesn't feel like we've really 
talked through how exactly we expect the version number game to play out 
over time ... 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 addss some new features) but we also want 
to release a new major version of solr that breaks compatibility with 
solr-3.2 ... so what do we call that?

in short: trying to sync version numbers seems like a pain with very 
little beenfit -- version numbers should communicate significance of 
change, not dependency information.

: - remove deprecations (finally!), and perhaps some additional cleanups
: that we've wanted to do

As long as we bump the major version number to communicate the 
significance, i'm all in favor of purging deprecations anytime people 
want.


-Hoss


  

Re: rough outline of where Solr's going

2010-03-16 Thread Ted Dunning
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 end-user. A minor change in Lucene
 could cause major changes in Solr. And vice-versa, a major change in Lucene
 could actually result in very little change for the Solr end user.



Re: rough outline of where Solr's going

2010-03-16 Thread Yonik Seeley
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 addss some new features) but we also want
 to release a new major version of solr that breaks compatibility with
 solr-3.2 ... so what do we call that?

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 could it do so w/o lucene doing that?  It's the same issue.

-Yonik


Re: rough outline of where Solr's going

2010-03-16 Thread Chris Hostetter

: 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 could it do so w/o lucene doing that?  It's the same issue.

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.

But the way that changes is made may not have any impact on how that 
functionality is ultimately exposed in Solr -- the core user based is 
all JAva developers who care a lot about the Java API -- the solr user 
based are typically not Java users, and have very little concern for what 
the Java internals look like -- in every release Solr has changed internal 
APIs in a way that was deeemed small enough to be acceptable to the 
(small) percentage of the user population that writes plugins, but those 
same changes in Lucene-Java would have mandated a major version change.

The main issue i'm trying to raise is the opposite of your example: when a 
committer wants to make a big change to solr (frontend) code which will 
have a big impact on how users interact with Solr, but in no way shape or 
form affects the lucene core Java API ... how does that fit into a lock 
step version policy?




-Hoss



Re: rough outline of where Solr's going

2010-03-16 Thread Yonik Seeley
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, and
 : Solr wanted to make some big changes for a major version number bump?
 : How could it do so w/o lucene doing that?  It's the same issue.

 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 - w/o an attempt at synchronized releases,
I'm against of code/modules moving out of solr.  It get's to the heart
of why we merged in the first place.

-Yonik