You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Yonik Seeley <yo...@apache.org> on 2010/03/16 16:00:47 UTC
rough outline of where Solr's going
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
Posted by Yonik Seeley <ys...@gmail.com>.
On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless
<lu...@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
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 18, 2010, at 2:06 PM, Robert Muir wrote:
> On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless
> <lu...@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
Posted by Robert Muir <rc...@gmail.com>.
On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless
<lu...@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
rcmuir@gmail.com
Re: rough outline of where Solr's going
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 <rc...@gmail.com> wrote:
> On Thu, Mar 18, 2010 at 11:33 AM, Michael McCandless
> <lu...@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
> rcmuir@gmail.com
>
Re: rough outline of where Solr's going
Posted by Robert Muir <rc...@gmail.com>.
On Thu, Mar 18, 2010 at 11:33 AM, Michael McCandless
<lu...@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
rcmuir@gmail.com
Re: rough outline of where Solr's going
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Thu, Mar 18, 2010 at 8:20 AM, Marvin Humphrey <ma...@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
Posted by Marvin Humphrey <ma...@rectangular.com>.
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
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 17, 2010, at 9:41 PM, Yonik Seeley wrote:
> On Wed, Mar 17, 2010 at 9:16 PM, Grant Ingersoll <gs...@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
Posted by Yonik Seeley <ys...@gmail.com>.
On Wed, Mar 17, 2010 at 9:16 PM, Grant Ingersoll <gs...@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
Posted by Grant Ingersoll <gs...@apache.org>.
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
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
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.Mattmann@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
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Posted by Yonik Seeley <yo...@apache.org>.
On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter
<ho...@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
Posted by Lukáš Vlček <lu...@gmail.com>.
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 <ma...@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
Posted by Yonik Seeley <ys...@gmail.com>.
On Thu, Mar 18, 2010 at 2:49 PM, Chris Hostetter
<ho...@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
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
>
>
> : 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.Mattmann@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
Posted by Mark Miller <ma...@gmail.com>.
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
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Posted by Mark Miller <ma...@gmail.com>.
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
Posted by Ryan McKinley <ry...@gmail.com>.
>
> 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
Posted by Grant Ingersoll <gs...@apache.org>.
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
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Posted by Yonik Seeley <ys...@gmail.com>.
On Thu, Mar 18, 2010 at 2:36 PM, Chris Hostetter
<ho...@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
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
>
> : 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.Mattmann@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
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
On 3/18/10 11:25 AM, "Yonik Seeley" <ys...@gmail.com> wrote:
> On Thu, Mar 18, 2010 at 2:16 PM, Chris Hostetter
> <ho...@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.Mattmann@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
Posted by Yonik Seeley <ys...@gmail.com>.
On Thu, Mar 18, 2010 at 2:16 PM, Chris Hostetter
<ho...@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
Posted by Chris Hostetter <ho...@fucit.org>.
: > 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
Posted by Yonik Seeley <ys...@gmail.com>.
On Thu, Mar 18, 2010 at 2:01 PM, Chris Hostetter
<ho...@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
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter
<ho...@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
rcmuir@gmail.com
Re: rough outline of where Solr's going
Posted by Chris Hostetter <ho...@fucit.org>.
: > 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
Posted by Yonik Seeley <yo...@apache.org>.
On Tue, Mar 16, 2010 at 2:25 PM, Chris Hostetter
<ho...@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
Re: rough outline of where Solr's going
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Mar 16, 2010 at 1:47 PM, Chris Hostetter
<ho...@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
Posted by Ted Dunning <te...@gmail.com>.
The key word here is "end-user".
On Tue, Mar 16, 2010 at 10:57 AM, Kevin Osborn <os...@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
Posted by Kevin Osborn <os...@yahoo.com>.
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 <ho...@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
Posted by Chris Hostetter <ho...@fucit.org>.
: - 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
Posted by Bill Au <bi...@gmail.com>.
+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
Posted by Yonik Seeley <yo...@apache.org>.
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
Posted by Yonik Seeley <yo...@apache.org>.
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
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Mar 16, 2010 at 10:45 AM, Grant Ingersoll <gs...@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
Posted by Grant Ingersoll <gs...@apache.org>.
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