>
> 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 go
>
>
> : 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 200
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
: 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) we
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
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
>
> : 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 re
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 a
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 has
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
: 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,
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 -
: 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
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
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
: > I thinks solr-3.1 only makes sense if Solr is include in one big
: > giant apache-lucene-3.1.tgz release
:
: Projects have multiple artifacts all the time for user convenience.
Ugh ... sorry, poor phrasing on my part ... i was not suggesting that we
*should* have a single monolithic release
On Thu, Mar 18, 2010 at 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
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 Spri
: 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 r
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 indir
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 incl
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
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 th
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 a
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".
>
>
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 doe
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 suppo
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 th
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
: 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 nex
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
> : > cer
: > 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 i
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
: 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
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)
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 c
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 ve
: - 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
+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 inclu
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
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
>> -
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 simplicit
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
43 matches
Mail list logo
