Andi Vajda wrote:
>
> On Mon, 24 Aug 2009, Tim Smith wrote:
>
>> Here's my vote on the topic of 2.9 vs 3.0
>>
>> Next release should be 2.9
>> This release provides TONs of new APIs for things like Hit Collection,
>> Scoring, Sorting, etc
>> If all the deprecated stuff were removed for the "next" r
On Sun, 23 Aug 2009, Mark Miller wrote:
I'm still +1 on calling this 3.0 as I was before when you mentioned it.
Its a wakeup call that the upgrade is a bit major in certain areas.
In either case - 3.0 is more representative of what this release is IMO.
I also think we should allow new feature
On Sun, 23 Aug 2009, Michael McCandless wrote:
Right, this (you can jump to 2.9, fix all deprecations, then easily
move to 3.0 and see no deprecations) is my understanding too, but I
don't see what's particularly useful about that. It does produce a
Lucene release that has zero deprecated APIs
On Mon, 24 Aug 2009, Tim Smith wrote:
Here's my vote on the topic of 2.9 vs 3.0
Next release should be 2.9
This release provides TONs of new APIs for things like Hit Collection,
Scoring, Sorting, etc
If all the deprecated stuff were removed for the "next" release, this would
be impossible for
On Mon, Aug 24, 2009 at 10:15:20PM +0300, Shai Erera wrote:
> I think it all boils down to this jar drop-in ability.
Expecting jar drop-in compatibility for bugfix releases is 100% reasonable.
Expecting something close to jar drop-in compatibility for minor releases
seems pretty reasonable, too.
I don't mean to stir the ocean again, but I think it all boils down to this
jar drop-in ability. If someone plans to upgrade to 2.9 by just dropping in
a jar, then I'd like to hear of that someone who succeeded. 2.9 already
contains back-compat breaks. So that someone must be using Lucene is such a
On Mon, Aug 24, 2009 at 01:46:35PM -0400, Michael McCandless wrote:
> Right, that is and has been the "plan" for 2.9/3.0/3.1 for quite some time.
>
> We are now discussing whether to change the plan, but so far it looks
> likely we'll just stick with it...
It seems like breaking the promise woul
On Mon, Aug 24, 2009 at 1:32 PM, Jason
Rutherglen wrote:
> I don't like to chime in about these things because I don't
> really care too much, but it seemed like (for the last several
> months), 2.9 was going to be on Java 1.4, then 3.0 would include
> deprectations (maybe bug fixes). Then 3.1 was
> * Do we label the next release 2.9 or 3.0?
> * After that next release, do we do a "fast turnaround"
release or a > more normal "take your time and do real work"
release?
I don't like to chime in about these things because I don't
really care too much, but it seemed like (for the last several
mo
On Mon, Aug 24, 2009 at 11:44:17AM -0400, Michael McCandless wrote:
> Separately, we can think about having 3.1 be a "real" release, not
> just a "fast turnaround" release.
All problems flow from this "fast turnaround release" constraint.
If you had the freedom to make the kind of API changes pe
I was suggesting that 3.0 is simply a "name change" of 2.9, because of
the big number of new features.
Meaning, we then drop deprecated APIs, add generics, change defaults,
etc., in 3.1.
Separately, we can think about having 3.1 be a "real" release, not
just a "fast turnaround" release.
But this
> You make a great point. If we jump to 3.0, what do we do about the
> deprecation drop?
>
> If we drop them now, it would be quite a fun upgrade experience :)
My nice TokenStream backwards layer will gone? Oh no :-) - Just kidding.
> Tim Smith wrote:
> > Here's my vote on the topic of 2.9 vs 3
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
_
From: Tim Smith [mailto:tsm...@attivio.com]
Sent: Monday, August 24, 2009 2:19 PM
To: java-dev@lucene.apache.org
Subject: Re: Finishing Lucene 2.9
Here's my vote on the topic of 2
You make a great point. If we jump to 3.0, what do we do about the
deprecation drop?
If we drop them now, it would be quite a fun upgrade experience :)
- Mark
Tim Smith wrote:
> Here's my vote on the topic of 2.9 vs 3.0
>
> Next release should be 2.9
> This release provides TONs of new APIs for
Here's my vote on the topic of 2.9 vs 3.0
Next release should be 2.9
This release provides TONs of new APIs for things like Hit Collection,
Scoring, Sorting, etc
If all the deprecated stuff were removed for the "next" release, this
would be impossible for any application developer to consume (unle
On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir wrote:
> But isn't it also true it could be a bit more than no-op:
> 1) changing to "better" defaults in cases where back compat prevents
> this. I think I remember a few of these?
> 2) bugfixes found after release of 2.9
> 3) performance improvements, n
On Aug 23, 2009, at 2:06 PM, Simon Willnauer wrote:
On Sun, Aug 23, 2009 at 7:38 PM, Robert Muir wrote:
just wanted to mention this (i honestly don't have any opinion
either way):
Right, this (you can jump to 2.9, fix all deprecations, then easily
move to 3.0 and see no deprecations) is my
Simon Willnauer wrote:
>
> Having 3.0
> with 1.4 back-compat and then 3.1 which get rid of this would confuse
> users.
>
> simon
>
>
If that was really a concern (and we decided to jump to 3.0), we could
just say this 3.0 release requires Java 1.5 - 3.0 and beyond can still
be considered Java 1
On Sun, Aug 23, 2009 at 7:38 PM, Robert Muir wrote:
> just wanted to mention this (i honestly don't have any opinion either way):
>
>> Right, this (you can jump to 2.9, fix all deprecations, then easily
>> move to 3.0 and see no deprecations) is my understanding too, but I
>> don't see what's parti
just wanted to mention this (i honestly don't have any opinion either way):
> Right, this (you can jump to 2.9, fix all deprecations, then easily
> move to 3.0 and see no deprecations) is my understanding too, but I
> don't see what's particularly useful about that. It does produce a
> Lucene rel
I'm still +1 on calling this 3.0 as I was before when you mentioned it.
Its a wakeup call that the upgrade is a bit major in certain areas.
In either case - 3.0 is more representative of what this release is IMO.
I also think we should allow new features in 3.0 if we release this as 2.9.
- Mark
Right, this (you can jump to 2.9, fix all deprecations, then easily
move to 3.0 and see no deprecations) is my understanding too, but I
don't see what's particularly useful about that. It does produce a
Lucene release that has zero deprecated APIs (assuming we remove all
of them), but I don't thin
On 8/19/09 2:37 PM, Mark Miller wrote:
I hadn't settled on me being the RM yet ;) Though if no one else steps
up, I will be.
I'd do it, but I'm going on vacation September 3rd for a bit more than 2
weeks and won't have internet access most of the time. I think 2 weeks
is not enough time to
3:51 AM
To: java-dev@lucene.apache.org
Subject: Re: Finishing Lucene 2.9
Please read the archives on the 1.5 move. We have discussed it many times.
There is also a Wiki page on it under the committers section. While
technically it breaks back compatibility, we are going forward with it and
we decided to
>
>>>
>>> -
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>>
>>> ------------
>>> *From:* Shai Erera [mailto:ser...@gmai
:ser...@gmail.com]
>> *Sent:* Thursday, August 20, 2009 3:05 PM
>> *To:* java-dev@lucene.apache.org <mailto:java-dev@lucene.apache.org>
>> *Subject:* Re: Finishing Lucene 2.9
>>
>>
>> What will be w/ generics? Won't they break cack-compat as soon as we
a-dev@lucene.apache.org
Subject: Re: Finishing Lucene 2.9
What will be w/ generics? Won't they break cack-compat as soon as we
add them (e.g., if we move to accepting parameters as generics - it
may break an application which does not use generics yet). I think
that the move to 1.5 needs
remen
http://www.thetaphi.de
eMail: u...@thetaphi.de
_
From: Shai Erera [mailto:ser...@gmail.com]
Sent: Thursday, August 20, 2009 3:05 PM
To: java-dev@lucene.apache.org
Subject: Re: Finishing Lucene 2.9
What will be w/ generics? Won't they break cack-compat as soon as we add
them (e.g.
I don't think thats an issue? Generics use type erasure - its just
compile time - so its binary compatible with any previous code that
doesn't use generics.
- Mark
Shai Erera wrote:
> What will be w/ generics? Won't they break cack-compat as soon as we
> add them (e.g., if we move to accepting pa
What will be w/ generics? Won't they break cack-compat as soon as we add
them (e.g., if we move to accepting parameters as generics - it may break an
application which does not use generics yet). I think that the move to 1.5
needs to include the generics as well, unless we're willing to break
back-
Michael McCandless wrote:
> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller wrote:
>
>
>> I forgot about this oddity. Its so weird. Its like we are doing two
>> releases on top of each other - it just seems confusing.
>>
>
> I'm also not wed to the "fast turnaround" (remove deprecations, switc
On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller wrote:
> I forgot about this oddity. Its so weird. Its like we are doing two
> releases on top of each other - it just seems confusing.
I'm also not wed to the "fast turnaround" (remove deprecations, switch
to generics) 3.0 release.
We could, instead,
On 8/19/09 3:16 PM, Uwe Schindler wrote:
0 issues! Congrats everyone. 2.9 was quite a beast.
So looks like we should get a few things in order.
1. Anyone dying to be release manager? I think I could do it, but I'm
kind of pressed for time ...
2. Lets start crawling all over this release - bugs
Uwe Schindler wrote:
>> 0 issues! Congrats everyone. 2.9 was quite a beast.
>>
>> So looks like we should get a few things in order.
>>
>> 1. Anyone dying to be release manager? I think I could do it, but I'm
>> kind of pressed for time ...
>>
>> 2. Lets start crawling all over this release - bugs/
> 0 issues! Congrats everyone. 2.9 was quite a beast.
>
> So looks like we should get a few things in order.
>
> 1. Anyone dying to be release manager? I think I could do it, but I'm
> kind of pressed for time ...
>
> 2. Lets start crawling all over this release - bugs/javadoc/packaging etc.
>
I hadn't settled on me being the RM yet ;) Though if no one else steps
up, I will be.
I was suggesting a kind of earlier, looser test jar than what we have
previously done as an RC (essentially a nightly (which are hard to find
lately IME - last one I got I had to dig through Hudson) of trunk)
When I was the RM I usually sent out a note in advance with a tentative
schedule, i.e. code freeze date, length of code freeze period, release
date (again, all tentative of course). Then the community could give
feedback on that proposed schedule and could plan accordingly.
Michael
On 8/19/0
On 8/19/09 11:43 AM, Grant Ingersoll wrote:
On Aug 19, 2009, at 2:13 PM, Yonik Seeley wrote:
On Wed, Aug 19, 2009 at 1:52 PM, Grant Ingersoll
wrote:
the RM should follow the release procedure as specified.
Wiki documents are normally not official - anyone can modify them, and
people have be
Not sure - though if not now, than extremely imminently. I have no
problem giving a bit of time for people to weigh in on that.
I'm trying to get a feel for what the community wants to do before
actually putting
anything up or sending anything out to java-user. I'm prepped to go when
it makes
So, are we under a code freeze now? And only doing doc/breakers?
-Grant
On Aug 19, 2009, at 3:08 PM, Mark Miller wrote:
Okay, I can do the test/beta release dist and host on
people.apache.org.
Anyone have any pref on what we call this? Its not really a release
candidate per say, though I
Okay, I can do the test/beta release dist and host on people.apache.org.
Anyone have any pref on what we call this? Its not really a release
candidate per say, though I have no
problem calling it that. We can go from rc1 to rc20 for all it matters.
--
- Mark
http://www.lucidimagination.com
On Aug 19, 2009, at 2:13 PM, Yonik Seeley wrote:
On Wed, Aug 19, 2009 at 1:52 PM, Grant
Ingersoll wrote:
the RM should follow the release procedure as specified.
Wiki documents are normally not official - anyone can modify them, and
people have been with little/no discussion. I'll admit th
On Wed, Aug 19, 2009 at 1:52 PM, Grant Ingersoll wrote:
> the RM should follow the release procedure as specified.
Wiki documents are normally not official - anyone can modify them, and
people have been with little/no discussion. I'll admit that I can't
always follow java-dev, so I may have misse
On Aug 19, 2009, at 11:17 AM, Yonik Seeley wrote:
A final note - AFAIK, the ReleaseTodo
http://wiki.apache.org/jakarta-lucene/ReleaseTodo is for the purpose
of helping people do releases - it's not an official release process
where every step must be followed... these are only guidelines.
There'
On Wed, Aug 19, 2009 at 10:49 AM, Mark Miller wrote:
> 3. In regards to that - I'd like to suggest that we don't do the release
> branch early for 2.9. I know we normally make the release
> branch so that further dev can continue on trunk. In this case I don't
> think that is wise. I propose that
0 issues! Congrats everyone. 2.9 was quite a beast.
So looks like we should get a few things in order.
1. Anyone dying to be release manager? I think I could do it, but I'm
kind of pressed for time ...
2. Lets start crawling all over this release - bugs/javadoc/packaging etc.
3. In regards t
Yay!
Mike
On Tue, Aug 18, 2009 at 3:26 PM, Mark Miller wrote:
> Looks like everyone plans on committing the remaining issues today (though
> Robert has one that he may wait a day or two for).
>
> Awesome!
>
> - Mark
>
> -
> To un
Looks like everyone plans on committing the remaining issues today
(though Robert has one that he may wait a day or two for).
Awesome!
- Mark
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional comm
> release branch. Here is whats holding us up:
>
> LUCENE-1768 NumericRange support for new query parser
>
> This issue looks troublesome. Anyone know if its likely to be resolved
> soon? I see that Yonik has suggested pushing it till the next release.
> Because the new QueryParser is not yet sla
Mark Miller wrote:
Thanks to everyones hard work, Lucene 2.9 is nearly upon us. We have
been swirling around 5 or so issues for some time – but its finally
looking like we can hit the magic '0' number this week, barring many
new surprises.
I'd love to see that by the end of the week if at all
On 8/17/09 3:51 PM, Mark Miller wrote:
Thanks to everyones hard work, Lucene 2.9 is nearly upon us. We have
been swirling around 5 or so issues for some time – but its finally
looking like we can hit the magic '0' number this week, barring many
new surprises.
I'd love to see that by the end o
51 matches
Mail list logo
