Re: rough outline of where Solr's going
> > 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
> > > : 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
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
: 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
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
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 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
> > : 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
On 3/18/10 11:25 AM, "Yonik Seeley" wrote: > On Thu, Mar 18, 2010 at 2:16 PM, Chris Hostetter > 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
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
On Thu, Mar 18, 2010 at 2: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. 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
: 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
On Thu, Mar 18, 2010 at 2:36 PM, Chris Hostetter 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
: 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
On Mar 18, 2010, at 2:06 PM, Robert Muir wrote: > On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless > 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
On Thu, Mar 18, 2010 at 2:16 PM, Chris Hostetter 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
: > 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
On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless 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
On Thu, Mar 18, 2010 at 2:01 PM, Chris Hostetter 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
: 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
On Thu, Mar 18, 2010 at 1:12 PM, Michael McCandless 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
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 wrote: > On Thu, Mar 18, 2010 at 11:33 AM, Michael McCandless > 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
On Thu, Mar 18, 2010 at 11:33 AM, Michael McCandless 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
On Thu, Mar 18, 2010 at 8:20 AM, Marvin Humphrey 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
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
On Mar 17, 2010, at 9:41 PM, Yonik Seeley wrote: > On Wed, Mar 17, 2010 at 9:16 PM, Grant Ingersoll 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
On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter 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
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
On Wed, Mar 17, 2010 at 9:16 PM, Grant Ingersoll 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
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
: 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
On Wed, Mar 17, 2010 at 8:15 PM, Chris Hostetter 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
: > 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
On Tue, Mar 16, 2010 at 2:25 PM, Chris Hostetter 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
: 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
On Tue, Mar 16, 2010 at 1:47 PM, Chris Hostetter 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
The key word here is "end-user". On Tue, Mar 16, 2010 at 10:57 AM, Kevin Osborn 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
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 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
: - 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
+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 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 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 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
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 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 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
On Tue, Mar 16, 2010 at 10:45 AM, Grant Ingersoll 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
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
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 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 >
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