You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Mark Miller <ma...@gmail.com> on 2009/08/18 00:51:45 UTC
Finishing Lucene 2.9
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 possible. It
hasn't been a bad thing that wrap up has taken this long – its given our
brave trunk user community more time to flag and test the issues we have
been cramming in lately – but it seems to me its about time to start a
real testing period on something more stable. If we can get down to 0
issues by the end of the week, I think we will be ready to make the
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 slated to replace the old, it
seems this one is no longer the blocker issue it appeared to be? Would
be great to get info either way.
LUCENE-1791 Enhance QueryUtils and CheckHIts to wrap everything they
check in MultiReader/MultiSearcher
I believe has is ready to commit this one – essentially done.
LUCENE-1692 Contrib analyzers need tests
Robert is about to commit this one – essentially done.
LUCENE-1813 Add option to ReverseStringFilter to mark reversed tokens
Looks like there is a bit left to do, but that this will likely be done
this week.
LUCENE-1792 new QueryParser fails to set AUTO REWRITE for multi-term queries
Our other problem child. Hows it looking on finishing this? I see
Michael is still waiting on an apply-able patch. Looks like this and
1768 are the only possible hold ups at the moment.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Luis Alves <la...@gmail.com>.
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 possible. It
> hasn't been a bad thing that wrap up has taken this long – its given
> our brave trunk user community more time to flag and test the issues
> we have been cramming in lately – but it seems to me its about time to
> start a real testing period on something more stable. If we can get
> down to 0 issues by the end of the week, I think we will be ready to
> make the release branch. Here is whats holding us up:
>
> LUCENE-1768 NumericRange support for new query parser
I also thing we should defer this one.
>
> 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 slated to replace the old, it
> seems this one is no longer the blocker issue it appeared to be? Would
> be great to get info either way.
>
> LUCENE-1791 Enhance QueryUtils and CheckHIts to wrap everything they
> check in MultiReader/MultiSearcher
>
> I believe has is ready to commit this one – essentially done.
>
> LUCENE-1692 Contrib analyzers need tests
>
> Robert is about to commit this one – essentially done.
>
> LUCENE-1813 Add option to ReverseStringFilter to mark reversed tokens
>
> Looks like there is a bit left to do, but that this will likely be
> done this week.
>
> LUCENE-1792 new QueryParser fails to set AUTO REWRITE for multi-term
> queries
Just finished the last patch a few minutes ago, should be ready for 2.9
>
> Our other problem child. Hows it looking on finishing this? I see
> Michael is still waiting on an apply-able patch. Looks like this and
> 1768 are the only possible hold ups at the moment.
>
>
--
-Lafa
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael Busch <bu...@gmail.com>.
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 get 2.9 out...
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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) -
just for users that havn't built from svn, and wouldn't normally go
through the hassle. The more users testing the earlier, the better. And
that is what I was volunteering to do. However, looking at the Release
TODO's, this still really fits the mold anyway. No need to do anything
special I guess - just get to the RC step quickly I suppose - and
knowing that other rcs are likely to follow.
- Mark
Michael Busch wrote:
> 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/09 1:19 PM, Mark Miller wrote:
>> 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 sense.
>>
>> - Mark
>>
>> Grant Ingersoll wrote:
>>> 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 have no
>>>> problem calling it that. We can go from rc1 to rc20 for all it
>>>> matters.
>>>>
>>>> --
>>>> - Mark
>>>>
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael Busch <bu...@gmail.com>.
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/09 1:19 PM, Mark Miller wrote:
> 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 sense.
>
> - Mark
>
> Grant Ingersoll wrote:
>> 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 have no
>>> problem calling it that. We can go from rc1 to rc20 for all it matters.
>>>
>>> --
>>> - Mark
>>>
>>> http://www.lucidimagination.com
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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 sense.
- Mark
Grant Ingersoll wrote:
> 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 have no
>> problem calling it that. We can go from rc1 to rc20 for all it matters.
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Grant Ingersoll <gs...@apache.org>.
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 have no
> problem calling it that. We can go from rc1 to rc20 for all it
> matters.
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael Busch <bu...@gmail.com>.
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<gs...@apache.org>
>> 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 missed a vote to codify/upgrade
>> this release guideline as an official process that must be followed.
>>
>> At least I know that's not the case in Solr-land though, and I've
>> updated the wiki to reflect that.
>
> I find it scary to think that one release might contain Maven
> artifacts, for instance, while another, done by a different person,
> might not, simply b/c the RM doesn't feel like it. I don't agree
> here, and I don't agree for Solr. Stable RM is as important as
> backward compatibility, if not more so.
+1. I too think that the RM should follow the guidelines.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Grant Ingersoll <gs...@apache.org>.
On Aug 19, 2009, at 2:13 PM, Yonik Seeley wrote:
> On Wed, Aug 19, 2009 at 1:52 PM, Grant
> Ingersoll<gs...@apache.org> 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 missed a vote to codify/upgrade
> this release guideline as an official process that must be followed.
>
> At least I know that's not the case in Solr-land though, and I've
> updated the wiki to reflect that.
I find it scary to think that one release might contain Maven
artifacts, for instance, while another, done by a different person,
might not, simply b/c the RM doesn't feel like it. I don't agree
here, and I don't agree for Solr. Stable RM is as important as
backward compatibility, if not more so.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Wed, Aug 19, 2009 at 1:52 PM, Grant Ingersoll<gs...@apache.org> 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 missed a vote to codify/upgrade
this release guideline as an official process that must be followed.
At least I know that's not the case in Solr-land though, and I've
updated the wiki to reflect that.
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Grant Ingersoll <gs...@apache.org>.
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's also no reason why the "release manager" needs to be the one
> to do all the items like run RAT, etc. That can be done by anyone
> interested - including other contributors who do not yet have commit
> privileges.
While I agree that anyone can do these things (run ant package, RAT,
etc), I don't think it is good for the RM to think of the Release
process merely as guidelines and the RM should follow the release
procedure as specified. The release process has been followed for
every release since 2.2. A repeatable release process is key to
creating reliable releases and instilling confidence in the community
as well as making sure the ASF legal requirements are met. We can,
of course, modify the process based on group consensus, but short of
that, I don't think it is up to the RM's discretion as to what they
think is important.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Wed, Aug 19, 2009 at 10:49 AM, Mark Miller<ma...@gmail.com> 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 we lock down trunk for a while, to
> force people to concentrate on *this* release. Otherwise we divide our
> limited forces into two - those working on release, and those working on
> trunk and beyond. We can kind of enforce this by making the release branch
> last minute I think.
+1
I've experienced the extra pain of having to merge every change from
branch up until the release (esp when the CHANGES.txt is different and
patch fails) - there's really no point - checkins for the next release
can normally wait.
> 4. I suggest we offer an early release candidate type build (very soon) -
> nothing official, nothing signed - just something easier for our user
> community to test with if they are not very familiar with building a release
> off of trunk.
+1
I've also observed people bringing up release nits only *after* an
official vote for a package has started - that messes up stuff like
trying to post-date in CHANGES. Developers should do "ant package"
*now* and bring up issues and objections while it's easy to fix - get
everything possible out of the way before the official VOTE thread.
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's also no reason why the "release manager" needs to be the one
to do all the items like run RAT, etc. That can be done by anyone
interested - including other contributors who do not yet have commit
privileges.
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael Busch <bu...@gmail.com>.
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/javadoc/packaging etc.
>>
>> 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 we lock down trunk for a
>> while, to force people to concentrate on *this* release. Otherwise we
>> divide our limited forces into two - those working on release, and those
>> working on trunk and beyond. We can kind of enforce this by making the
>> release branch last minute I think.
>>
> I think 3.0 is a little bit special: We move to Java 1.5, so in my opinion,
> we should not only remove deprecations, but also add Generics and remove
> StringBuffer and so on. I have some "patches" for that available, e.g. the
> casting currently needed for the Attributes API can be more elegantly solved
> by using generics (something like "T addAttribute(Class<T extends
> Attribute>)"). If we do not add generics to the public API in 3.0, we have
> to wait one major release longer to add them.
>
>
Yes, I added that already in the very first AttributeSource patch - it's
currently commented out
at the bottom of the class I think. Probably a bit out of date. I
definitely want to do that to improve
readability of the attributes, it's much nicer with generics. That's how
I started coding it and why
I started liking the syntax, before I needed to make it a bit ugly for
JDK 1.4.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Marvin Humphrey <ma...@rectangular.com>.
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.
Expecting jar drop-in compatibility minus deprecations at a major version
change is only reasonable when that has been made the explicit public policy
of the project. By making that promise, you are squandering your one
opportunity to make disruptive changes.
Instead, you're trying to shoehorn what ought to be disruptive changes into an
artificially continuous release cycle. It's a lot of work, results in a lot
of inelegant compatibility APIs, and seems not to have been successfully
implemented yet for 2.9.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Shai Erera <se...@gmail.com>.
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
basic way, that I find it hard to imagine that someone would upgrade to 2.9
at all (I don't recall any serious bugs that were fixed).
Other than that, like was said on this thread several times already, anyone
who upgrades to 2.9 (I use anyone inclusively) will probably clean his code
from all "deprecated" warnings and move to use the new API, because
otherwise he'll need to do it in 3.0. And for all those people, 3.0 would
just be a 1.5 upgrade, and I'd bet people out there already on 1.5 would
want to take advantage of the new API w/ generics, so that means another
code change?
I don't care too much, because I'll probably update my code after every
Lucene release. This is just to save some work for the RMs, and reduce the
confusion around the community (e.g., someone who already plans to change
his code anyway might decide to wait for 3.0 and do a major code update to
his application).
My two cents,
Shai
On Mon, Aug 24, 2009 at 9:11 PM, Marvin Humphrey <ma...@rectangular.com>wrote:
> 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 would be disruptive now. But you have
> an
> opportunity to change the policy at 3.0, affecting 3.9 and 4.0.
>
> That's a 3.0 issue, though -- not a 2.9 issue.
>
> Marvin Humphrey
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: Finishing Lucene 2.9
Posted by Marvin Humphrey <ma...@rectangular.com>.
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 would be disruptive now. But you have an
opportunity to change the policy at 3.0, affecting 3.9 and 4.0.
That's a 3.0 issue, though -- not a 2.9 issue.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Mon, Aug 24, 2009 at 1:32 PM, Jason
Rutherglen<ja...@gmail.com> 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 going to have some
> new functionality.
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...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Jason Rutherglen <ja...@gmail.com>.
> * 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
months), 2.9 was going to be on Java 1.4, then 3.0 would include
deprectations (maybe bug fixes). Then 3.1 was going to have some
new functionality.
On Mon, Aug 24, 2009 at 3:29 AM, Michael
McCandless<lu...@mikemccandless.com> wrote:
> On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir<rc...@gmail.com> 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, not just from #1 but also from removal of
>> back-compat shims (i.e. tokenstream reflection)
>
> Sorry, right, there are some defaults we will change.
>
> We may get bugfixes in, but if it's truly a "fast turnaround release",
> I think there wouldn't be that many bug fixes.
>
> And I agree on performance improvements for cases where the back
> compat emulation code was hurting performance.
>
> It seems like we have two questions:
>
> * 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?
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Marvin Humphrey <ma...@rectangular.com>.
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 people normally expect
to accompany a major version change, everything would be a lot simpler.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 clearly is rather confusing (even though it's a simple name
change, it's not following the back-compat policy, ie, we can't remove
deprecated APIs in 3.1), so maybe we should just stick with the
current plan, ie release 2.9 now and quickly thereafter 3.0 (w/ some
initial generics cutover, some defaults changed, all deprecated APIs
removed, but not that much else).
Mike
On Mon, Aug 24, 2009 at 8:21 AM, Mark Miller<ma...@gmail.com> wrote:
> 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 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 (unless
>> they are using very light high level use of lucene APIs)
>>
>> I would then vote for a very fast turnaround on 3.0
>> deprecations removed, generics added, performance improvements
>> possible with java 1.5, but no major new features
>> I would argue that small features should be allowed in (provided they
>> would not cause any postponement to 3.0 going out soon)
>>
>> This allows me (as a application developer) to do the following:
>> upgrade to 2.9 (port my code to use all the new APIs)
>> hopefully, once i have fully ported everything to 2.9, 3.0 will now be
>> ready (or will be soon)
>> then, i can drop in 3.0 (very minor porting required here) and all the
>> deprecated APIs with their slowing "wrapper" code for back-compat will
>> now be gone, along with improvements in using StringBuilder instead of
>> StringBuffer, generics, and other performance improvements.
>>
>> I would hope to never release any of my code running 2.9 and instead
>> release with 3.0, however as a app developer, i need 2.9 as a bridge
>> for porting
>>
>> -- Tim
>>
>>
>>
>> Michael McCandless wrote:
>>> On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir<rc...@gmail.com> 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, not just from #1 but also from removal of
>>>> back-compat shims (i.e. tokenstream reflection)
>>>>
>>>
>>> Sorry, right, there are some defaults we will change.
>>>
>>> We may get bugfixes in, but if it's truly a "fast turnaround release",
>>> I think there wouldn't be that many bug fixes.
>>>
>>> And I agree on performance improvements for cases where the back
>>> compat emulation code was hurting performance.
>>>
>>> It seems like we have two questions:
>>>
>>> * 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?
>>>
>>> Mike
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>>
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: Finishing Lucene 2.9
Posted by Uwe Schindler <uw...@thetaphi.de>.
> 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.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 (unless
> > they are using very light high level use of lucene APIs)
> >
> > I would then vote for a very fast turnaround on 3.0
> > deprecations removed, generics added, performance improvements
> > possible with java 1.5, but no major new features
> > I would argue that small features should be allowed in (provided they
> > would not cause any postponement to 3.0 going out soon)
> >
> > This allows me (as a application developer) to do the following:
> > upgrade to 2.9 (port my code to use all the new APIs)
> > hopefully, once i have fully ported everything to 2.9, 3.0 will now be
> > ready (or will be soon)
> > then, i can drop in 3.0 (very minor porting required here) and all the
> > deprecated APIs with their slowing "wrapper" code for back-compat will
> > now be gone, along with improvements in using StringBuilder instead of
> > StringBuffer, generics, and other performance improvements.
> >
> > I would hope to never release any of my code running 2.9 and instead
> > release with 3.0, however as a app developer, i need 2.9 as a bridge
> > for porting
> >
> > -- Tim
> >
> >
> >
> > Michael McCandless wrote:
> >> On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir<rc...@gmail.com> 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, not just from #1 but also from removal of
> >>> back-compat shims (i.e. tokenstream reflection)
> >>>
> >>
> >> Sorry, right, there are some defaults we will change.
> >>
> >> We may get bugfixes in, but if it's truly a "fast turnaround release",
> >> I think there wouldn't be that many bug fixes.
> >>
> >> And I agree on performance improvements for cases where the back
> >> compat emulation code was hurting performance.
> >>
> >> It seems like we have two questions:
> >>
> >> * 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?
> >>
> >> Mike
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: java-dev-help@lucene.apache.org
> >>
> >>
> >
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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 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 (unless
> they are using very light high level use of lucene APIs)
>
> I would then vote for a very fast turnaround on 3.0
> deprecations removed, generics added, performance improvements
> possible with java 1.5, but no major new features
> I would argue that small features should be allowed in (provided they
> would not cause any postponement to 3.0 going out soon)
>
> This allows me (as a application developer) to do the following:
> upgrade to 2.9 (port my code to use all the new APIs)
> hopefully, once i have fully ported everything to 2.9, 3.0 will now be
> ready (or will be soon)
> then, i can drop in 3.0 (very minor porting required here) and all the
> deprecated APIs with their slowing "wrapper" code for back-compat will
> now be gone, along with improvements in using StringBuilder instead of
> StringBuffer, generics, and other performance improvements.
>
> I would hope to never release any of my code running 2.9 and instead
> release with 3.0, however as a app developer, i need 2.9 as a bridge
> for porting
>
> -- Tim
>
>
>
> Michael McCandless wrote:
>> On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir<rc...@gmail.com> 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, not just from #1 but also from removal of
>>> back-compat shims (i.e. tokenstream reflection)
>>>
>>
>> Sorry, right, there are some defaults we will change.
>>
>> We may get bugfixes in, but if it's truly a "fast turnaround release",
>> I think there wouldn't be that many bug fixes.
>>
>> And I agree on performance improvements for cases where the back
>> compat emulation code was hurting performance.
>>
>> It seems like we have two questions:
>>
>> * 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?
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: Finishing Lucene 2.9
Posted by Uwe Schindler <uw...@thetaphi.de>.
This is exactly my own opinion. I would only add Java 1.5 with generics to
public API (most important the TokenStream stuff and also Field, also
NumericRangeQuery is prepared for generics: NumericRangeQuery<? Extends
Number>). I do not want to add generics everywhere inside, but to the public
API.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
_____
From: Tim Smith [mailto:tsmith@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.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 (unless they are
using very light high level use of lucene APIs)
I would then vote for a very fast turnaround on 3.0
deprecations removed, generics added, performance improvements possible with
java 1.5, but no major new features
I would argue that small features should be allowed in (provided they would
not cause any postponement to 3.0 going out soon)
This allows me (as a application developer) to do the following:
upgrade to 2.9 (port my code to use all the new APIs)
hopefully, once i have fully ported everything to 2.9, 3.0 will now be ready
(or will be soon)
then, i can drop in 3.0 (very minor porting required here) and all the
deprecated APIs with their slowing "wrapper" code for back-compat will now
be gone, along with improvements in using StringBuilder instead of
StringBuffer, generics, and other performance improvements.
I would hope to never release any of my code running 2.9 and instead release
with 3.0, however as a app developer, i need 2.9 as a bridge for porting
-- Tim
Michael McCandless wrote:
On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir <ma...@gmail.com>
<rc...@gmail.com> 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, not just from #1 but also from removal of
back-compat shims (i.e. tokenstream reflection)
Sorry, right, there are some defaults we will change.
We may get bugfixes in, but if it's truly a "fast turnaround release",
I think there wouldn't be that many bug fixes.
And I agree on performance improvements for cases where the back
compat emulation code was hurting performance.
It seems like we have two questions:
* 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?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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" release, this
>> would
>> be impossible for any application developer to consume (unless they are
>> using very light high level use of lucene APIs)
>>
>> I would then vote for a very fast turnaround on 3.0
>> deprecations removed, generics added, performance improvements
>> possible with
>> java 1.5, but no major new features
>> I would argue that small features should be allowed in (provided they
>> would
>> not cause any postponement to 3.0 going out soon)
>>
>> This allows me (as a application developer) to do the following:
>> upgrade to 2.9 (port my code to use all the new APIs)
>> hopefully, once i have fully ported everything to 2.9, 3.0 will now
>> be ready
>> (or will be soon)
>> then, i can drop in 3.0 (very minor porting required here) and all the
>> deprecated APIs with their slowing "wrapper" code for back-compat
>> will now
>> be gone, along with improvements in using StringBuilder instead of
>> StringBuffer, generics, and other performance improvements.
>>
>> I would hope to never release any of my code running 2.9 and instead
>> release
>> with 3.0, however as a app developer, i need 2.9 as a bridge for porting
>
> +1
>
> I'd add that 3.0 should also contain 2.9 bug fixes over new features.
> Consider 3.0 a 2.9.1 bug fix release with deprecations removed and
> Java 1.5 goodness :)
>
> Andi..
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
I'm not counting on any bugs in time for the 3.0 release. If you smell
them, point me to them.
Color me an optimist :)
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Andi Vajda <va...@osafoundation.org>.
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 any application developer to consume (unless they are
> using very light high level use of lucene APIs)
>
> I would then vote for a very fast turnaround on 3.0
> deprecations removed, generics added, performance improvements possible with
> java 1.5, but no major new features
> I would argue that small features should be allowed in (provided they would
> not cause any postponement to 3.0 going out soon)
>
> This allows me (as a application developer) to do the following:
> upgrade to 2.9 (port my code to use all the new APIs)
> hopefully, once i have fully ported everything to 2.9, 3.0 will now be ready
> (or will be soon)
> then, i can drop in 3.0 (very minor porting required here) and all the
> deprecated APIs with their slowing "wrapper" code for back-compat will now
> be gone, along with improvements in using StringBuilder instead of
> StringBuffer, generics, and other performance improvements.
>
> I would hope to never release any of my code running 2.9 and instead release
> with 3.0, however as a app developer, i need 2.9 as a bridge for porting
+1
I'd add that 3.0 should also contain 2.9 bug fixes over new features.
Consider 3.0 a 2.9.1 bug fix release with deprecations removed and Java 1.5
goodness :)
Andi..
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Tim Smith <ts...@attivio.com>.
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 (unless
they are using very light high level use of lucene APIs)
I would then vote for a very fast turnaround on 3.0
deprecations removed, generics added, performance improvements possible
with java 1.5, but no major new features
I would argue that small features should be allowed in (provided they
would not cause any postponement to 3.0 going out soon)
This allows me (as a application developer) to do the following:
upgrade to 2.9 (port my code to use all the new APIs)
hopefully, once i have fully ported everything to 2.9, 3.0 will now be
ready (or will be soon)
then, i can drop in 3.0 (very minor porting required here) and all the
deprecated APIs with their slowing "wrapper" code for back-compat will
now be gone, along with improvements in using StringBuilder instead of
StringBuffer, generics, and other performance improvements.
I would hope to never release any of my code running 2.9 and instead
release with 3.0, however as a app developer, i need 2.9 as a bridge for
porting
-- Tim
Michael McCandless wrote:
> On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir<rc...@gmail.com> 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, not just from #1 but also from removal of
>> back-compat shims (i.e. tokenstream reflection)
>>
>
> Sorry, right, there are some defaults we will change.
>
> We may get bugfixes in, but if it's truly a "fast turnaround release",
> I think there wouldn't be that many bug fixes.
>
> And I agree on performance improvements for cases where the back
> compat emulation code was hurting performance.
>
> It seems like we have two questions:
>
> * 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?
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: Finishing Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir<rc...@gmail.com> 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, not just from #1 but also from removal of
> back-compat shims (i.e. tokenstream reflection)
Sorry, right, there are some defaults we will change.
We may get bugfixes in, but if it's truly a "fast turnaround release",
I think there wouldn't be that many bug fixes.
And I agree on performance improvements for cases where the back
compat emulation code was hurting performance.
It seems like we have two questions:
* 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?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Lucene 3.0 and Java 5 (was Re: Finishing Lucene 2.9)
Posted by DM Smith <dm...@gmail.com>.
On Aug 23, 2009, at 2:06 PM, Simon Willnauer wrote:
> On Sun, Aug 23, 2009 at 7:38 PM, Robert Muir<rc...@gmail.com> 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 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 think that's very important. Also, it's
>>> extra work
>>> having to do a "no-op, except for deprecations removal and generics
>>> addition" release :)
>>
>> 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, not just from #1 but also from removal
>> of
>> back-compat shims (i.e. tokenstream reflection)
>>
>> I am not saying this stuff is really important to users to merit a
>> release, but I don't think it is a no-op either.
>
> I agree with robert that this is very likely not to be a no-op
> release. Changing to 1.5 brings in generics and lots of other stuff
> which could bring improvements. All the concurrent improvements,
> VarArgs and Utils in classes like Integer (valueOf) etc. I believe
> that we find may places in the code where existing stuff could be
> improved with the ability to commit 1.5 code.
> Moving to 1.5 with 3.0 would be a clean step in my eyes. Having 3.0
> with 1.4 back-compat and then 3.1 which get rid of this would confuse
> users.
My two cents. I think the contract of the 3.0 release is that it is a
drop in replacement for the 2.9 release but requires Java 1.5. I
expect to compile against Lucene 2.9 using Java 1.4, removing
deprecations. And then go to Lucene 3.0 changing the compiler to Java
1.5 but making no code changes.
To that end, any introduction of Java 1.5 into the end-user/non-expert/
non-experimental/non-contrib API needs to work with existing code as
is. It may require the user to compile with lax permissions using Java
1.5 and run with Java 1.5.
Requiring Java 1.5 can be as easy as using a Java 1.5 feature
internally, in the expert or experimental APIs, and classes that are
not part of the backward compatibility contract (e.g. utility classes).
I don't think there should be any effort to maintain Java 1.4
compatibility, but I also think changes should be made only where it
makes sense, giving a clear advantage (performance,
maintainability, ....). If that results in 1.4 compatibility it is a
temporary benefit not guaranteed during the 3.x series.
I agree with previous threads that there is both a blessing and a
curse with Lucene's backward compatibility release policy. My biggest
gripe is the evolution toward bad class names. I would like to see a
4.0 release dedicated to fixing the name/api problems and making the
API of Lucene be what it should have been for a 3.0 release. I'd also
suggest that repackaging, suggested in a prior thread, be tackled
also. This could follow a 3.0 release quickly.
-- DM Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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.5. Even though 3.0 itself still happens to run on
Java 1.4. We are not going to convert *everything* to Java 1.5 when we
move to it on the first release. We also don't have to convert anything
to say we now require it.
Personally, I wouldn't be too worried about it either way. Following
Changes correctly and with a solid understanding is 100x times more
difficult and confusing.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Simon Willnauer <si...@googlemail.com>.
On Sun, Aug 23, 2009 at 7:38 PM, Robert Muir<rc...@gmail.com> 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 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 think that's very important. Also, it's extra work
>> having to do a "no-op, except for deprecations removal and generics
>> addition" release :)
>
> 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, not just from #1 but also from removal of
> back-compat shims (i.e. tokenstream reflection)
>
> I am not saying this stuff is really important to users to merit a
> release, but I don't think it is a no-op either.
I agree with robert that this is very likely not to be a no-op
release. Changing to 1.5 brings in generics and lots of other stuff
which could bring improvements. All the concurrent improvements,
VarArgs and Utils in classes like Integer (valueOf) etc. I believe
that we find may places in the code where existing stuff could be
improved with the ability to commit 1.5 code.
Moving to 1.5 with 3.0 would be a clean step in my eyes. Having 3.0
with 1.4 back-compat and then 3.1 which get rid of this would confuse
users.
simon
>
> --
> Robert Muir
> rcmuir@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Robert Muir <rc...@gmail.com>.
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 release that has zero deprecated APIs (assuming we remove all
> of them), but I don't think that's very important. Also, it's extra work
> having to do a "no-op, except for deprecations removal and generics
> addition" release :)
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, not just from #1 but also from removal of
back-compat shims (i.e. tokenstream reflection)
I am not saying this stuff is really important to users to merit a
release, but I don't think it is a no-op either.
--
Robert Muir
rcmuir@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Andi Vajda <va...@osafoundation.org>.
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 (assuming we remove all
> of them), but I don't think that's very important. Also, it's extra work
> having to do a "no-op, except for deprecations removal and generics
> addition" release :)
It's a clean break with the past, well worth the release effort.
There is no such thing as a no-op release. I'm sure people will find bugs or
usability issues with 2.9 days after it's released. Rapidly fixing some of
these in 3.0 would be a nice gesture.
- remove deprecations
- fix important/obvious bugs reported since 2.9
- move a few 1.5 things in like StringBuilder to cast 1.5 use in stone (and
set expectations accordingly)
- release 3.0
In other words, 3.0 is really a 2.9.1 bug fix release with a few extra
things requiring the major version increment.
Andi..
>
> Vs say taking our time creating 3.0, letting it have real features,
> etc.
>
> Or, another option would be to simply release 3.0 next. After all,
> there are some seriously major changes in this release, compilation
> breakage, etc. ... things you'd more expect (of "traditional"
> software) in a .0 release. And, then state clearly that all
> deprecated APIs in 3.0 will be removed in 3.1. While this is
> technically a change to our back-compat policy, it's also just a
> number-shifting game since it would just be a rename
> (2.9 becomes 3.0; 3.0 becomes 3.1).
>
> Mike
>
> On Thu, Aug 20, 2009 at 8:58 AM, Mark Miller<ma...@gmail.com> wrote:
>> Michael McCandless wrote:
>>> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
>>> include new features too.
>>>
>>> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
>>> but I can't remember it nor find it now...
>>>
>>> Mike
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>> I thought the motivation was to provide a clean upgrade path with the
>> deprecations - you move to 2.9 and move from all the deprecated methods
>> - then you move to 3.0 and your good with no deprecations. I'd guess the
>> worry is that new features in 3.0 would add new deprecations and its not
>> quite so clean?
>>
>> Personally, I think thats fine though. New deprecations will come in 3.1
>> anyway. You can still move everything in 2.9, and then move to 3.0 - so
>> what if something else is now deprecated? You can move again or wait for
>> 3.9 to move ...
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Andi Vajda <va...@osafoundation.org>.
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 features in 3.0 if we release this as 2.9.
Sure, as long as they don't go against the "fast turnaround" goal.
As for version number, I think that the pending release number should be 2.9
(as in 3.0 with lots of back compat and 1.4 baggage), and the next one be
3.0, following shortly (say, three weeks later) after 2.9.
As for backwards compatility, I think there should be a blanket amnesty on
backwards compatibility breaks for 2.9 - 3.0 - 3.0.x,y,z - 3.1 so that the
APIs can be made sane, consistent and free of back compat compromises. It is
difficult to get all of this right in one release, for sure. Exposing faster
releases to more users and setting expectations accordingly would be a win
for the next few releases, I think.
Just my $0.02...
Andi..
>
> - Mark
>
>
> 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 (assuming we remove all
>> of them), but I don't think that's very important. Also, it's extra work
>> having to do a "no-op, except for deprecations removal and generics
>> addition" release :)
>>
>> Vs say taking our time creating 3.0, letting it have real features,
>> etc.
>>
>> Or, another option would be to simply release 3.0 next. After all,
>> there are some seriously major changes in this release, compilation
>> breakage, etc. ... things you'd more expect (of "traditional"
>> software) in a .0 release. And, then state clearly that all
>> deprecated APIs in 3.0 will be removed in 3.1. While this is
>> technically a change to our back-compat policy, it's also just a
>> number-shifting game since it would just be a rename
>> (2.9 becomes 3.0; 3.0 becomes 3.1).
>>
>> Mike
>>
>> On Thu, Aug 20, 2009 at 8:58 AM, Mark Miller<ma...@gmail.com> wrote:
>>
>>> Michael McCandless wrote:
>>>
>>>> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
>>>> include new features too.
>>>>
>>>> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
>>>> but I can't remember it nor find it now...
>>>>
>>>> Mike
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>>>
>>>>
>>> I thought the motivation was to provide a clean upgrade path with the
>>> deprecations - you move to 2.9 and move from all the deprecated methods
>>> - then you move to 3.0 and your good with no deprecations. I'd guess the
>>> worry is that new features in 3.0 would add new deprecations and its not
>>> quite so clean?
>>>
>>> Personally, I think thats fine though. New deprecations will come in 3.1
>>> anyway. You can still move everything in 2.9, and then move to 3.0 - so
>>> what if something else is now deprecated? You can move again or wait for
>>> 3.9 to move ...
>>>
>>> --
>>> - Mark
>>>
>>> http://www.lucidimagination.com
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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
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 (assuming we remove all
> of them), but I don't think that's very important. Also, it's extra work
> having to do a "no-op, except for deprecations removal and generics
> addition" release :)
>
> Vs say taking our time creating 3.0, letting it have real features,
> etc.
>
> Or, another option would be to simply release 3.0 next. After all,
> there are some seriously major changes in this release, compilation
> breakage, etc. ... things you'd more expect (of "traditional"
> software) in a .0 release. And, then state clearly that all
> deprecated APIs in 3.0 will be removed in 3.1. While this is
> technically a change to our back-compat policy, it's also just a
> number-shifting game since it would just be a rename
> (2.9 becomes 3.0; 3.0 becomes 3.1).
>
> Mike
>
> On Thu, Aug 20, 2009 at 8:58 AM, Mark Miller<ma...@gmail.com> wrote:
>
>> Michael McCandless wrote:
>>
>>> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
>>> include new features too.
>>>
>>> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
>>> but I can't remember it nor find it now...
>>>
>>> Mike
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>
>>>
>>>
>> I thought the motivation was to provide a clean upgrade path with the
>> deprecations - you move to 2.9 and move from all the deprecated methods
>> - then you move to 3.0 and your good with no deprecations. I'd guess the
>> worry is that new features in 3.0 would add new deprecations and its not
>> quite so clean?
>>
>> Personally, I think thats fine though. New deprecations will come in 3.1
>> anyway. You can still move everything in 2.9, and then move to 3.0 - so
>> what if something else is now deprecated? You can move again or wait for
>> 3.9 to move ...
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 think that's very important. Also, it's extra work
having to do a "no-op, except for deprecations removal and generics
addition" release :)
Vs say taking our time creating 3.0, letting it have real features,
etc.
Or, another option would be to simply release 3.0 next. After all,
there are some seriously major changes in this release, compilation
breakage, etc. ... things you'd more expect (of "traditional"
software) in a .0 release. And, then state clearly that all
deprecated APIs in 3.0 will be removed in 3.1. While this is
technically a change to our back-compat policy, it's also just a
number-shifting game since it would just be a rename
(2.9 becomes 3.0; 3.0 becomes 3.1).
Mike
On Thu, Aug 20, 2009 at 8:58 AM, Mark Miller<ma...@gmail.com> wrote:
> Michael McCandless wrote:
>> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
>> include new features too.
>>
>> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
>> but I can't remember it nor find it now...
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
> I thought the motivation was to provide a clean upgrade path with the
> deprecations - you move to 2.9 and move from all the deprecated methods
> - then you move to 3.0 and your good with no deprecations. I'd guess the
> worry is that new features in 3.0 would add new deprecations and its not
> quite so clean?
>
> Personally, I think thats fine though. New deprecations will come in 3.1
> anyway. You can still move everything in 2.9, and then move to 3.0 - so
> what if something else is now deprecated? You can move again or wait for
> 3.9 to move ...
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
I guess you could consider that you have to use 1.5 the break?
But I think that goes without saying ...
Mark Miller wrote:
> bq. While technically it breaks back compatibility,
>
> How does it break back compatibility? Generics are only compile time -
> they simply don't exist in the binary. Java itself is extremely back
> compat, so you can still use StringBuffer and the rest. I didn't find
> anything in the archives or the wiki that talks about a back compat
> break - that I can find anyway ...
>
>
> Grant Ingersoll wrote:
>
>> 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 allow generics, etc. right from the start.
>> We also didn't feel like we had to convert everything in one fell
>> swoop, either, as that will break many existing patches.
>>
>>
>> On Aug 20, 2009, at 4:29 PM, Uwe Schindler wrote:
>>
>>
>>> It would **not** break apps without generics, if the „upper” type is
>>> the same (which is easily fulfilled by my example with the
>>> AttributeSource). The whole 1.5 Java Collection API uses generics and
>>> 1.4 programs still run.
>>>
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Shai Erera [mailto:serera@gmail.com]
>>> *Sent:* Thursday, August 20, 2009 3:05 PM
>>> *To:* java-dev@lucene.apache.org <ma...@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 to include the generics as well, unless
>>> we're willing to break back-compat later on.
>>>
>>> Shai
>>>
>>> On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <markrmiller@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> Michael McCandless wrote:
>>>
>>>> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<markrmiller@gmail.com
>>>>
>>> <ma...@gmail.com>> 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, take out time doing the 3.0 release, ie let it
>>>> include new features too.
>>>>
>>>> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
>>>> but I can't remember it nor find it now...
>>>>
>>>> Mike
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>>
>>> <ma...@lucene.apache.org>
>>>
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>
>>> <ma...@lucene.apache.org>
>>>
>>>>
>>> I thought the motivation was to provide a clean upgrade path with the
>>> deprecations - you move to 2.9 and move from all the deprecated methods
>>> - then you move to 3.0 and your good with no deprecations. I'd guess the
>>> worry is that new features in 3.0 would add new deprecations and its not
>>> quite so clean?
>>>
>>> Personally, I think thats fine though. New deprecations will come in 3.1
>>> anyway. You can still move everything in 2.9, and then move to 3.0 - so
>>> what if something else is now deprecated? You can move again or wait for
>>> 3.9 to move ...
>>>
>>> --
>>> - Mark
>>>
>>> http://www.lucidimagination.com
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> <ma...@lucene.apache.org>
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>> <ma...@lucene.apache.org>
>>>
>>>
>>>
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com/
>>
>> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)
>> using Solr/Lucene:
>> http://www.lucidimagination.com/search
>>
>>
>
>
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
bq. While technically it breaks back compatibility,
How does it break back compatibility? Generics are only compile time -
they simply don't exist in the binary. Java itself is extremely back
compat, so you can still use StringBuffer and the rest. I didn't find
anything in the archives or the wiki that talks about a back compat
break - that I can find anyway ...
Grant Ingersoll wrote:
> 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 allow generics, etc. right from the start.
> We also didn't feel like we had to convert everything in one fell
> swoop, either, as that will break many existing patches.
>
>
> On Aug 20, 2009, at 4:29 PM, Uwe Schindler wrote:
>
>> It would **not** break apps without generics, if the „upper” type is
>> the same (which is easily fulfilled by my example with the
>> AttributeSource). The whole 1.5 Java Collection API uses generics and
>> 1.4 programs still run.
>>
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>
>> ------------------------------------------------------------------------
>> *From:* Shai Erera [mailto:serera@gmail.com]
>> *Sent:* Thursday, August 20, 2009 3:05 PM
>> *To:* java-dev@lucene.apache.org <ma...@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 to include the generics as well, unless
>> we're willing to break back-compat later on.
>>
>> Shai
>>
>> On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <markrmiller@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Michael McCandless wrote:
>> > On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<markrmiller@gmail.com
>> <ma...@gmail.com>> 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, take out time doing the 3.0 release, ie let it
>> > include new features too.
>> >
>> > I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
>> > but I can't remember it nor find it now...
>> >
>> > Mike
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> <ma...@lucene.apache.org>
>> > For additional commands, e-mail: java-dev-help@lucene.apache.org
>> <ma...@lucene.apache.org>
>> >
>> >
>> I thought the motivation was to provide a clean upgrade path with the
>> deprecations - you move to 2.9 and move from all the deprecated methods
>> - then you move to 3.0 and your good with no deprecations. I'd guess the
>> worry is that new features in 3.0 would add new deprecations and its not
>> quite so clean?
>>
>> Personally, I think thats fine though. New deprecations will come in 3.1
>> anyway. You can still move everything in 2.9, and then move to 3.0 - so
>> what if something else is now deprecated? You can move again or wait for
>> 3.9 to move ...
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> <ma...@lucene.apache.org>
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>> <ma...@lucene.apache.org>
>>
>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)
> using Solr/Lucene:
> http://www.lucidimagination.com/search
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: Finishing Lucene 2.9
Posted by Uwe Schindler <uw...@thetaphi.de>.
I know this docs. We also had the same discussion on java-dev half a year
ago.
Generics are not visible in the compiled java code, they are "erasured" and
replaced by their upper type (at least Object, like for Collection API). "E
Extends Attribute" in my example would be replaced by Attribute. Because of
that you can run old Java 1.1 programs still with Java 1.5 using the whole
collection API, which is the best example for Generics. If you be careful,
there is no backwards break beyond using a new class format and because of
that the requirement to upgrade to Java 1.5. The class format was updated,
to allow compilers, to get the generics information to check source code and
apply the correct tasks (this information is added to the class metadata).
The JVM itself is not using it, and because of that 1.4 programms just run
unmodified, even without recompiling.
Just read the tons of discussions/howtos on the web about the whole type
erasure.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
_____
From: Grant Ingersoll [mailto:gsingers@apache.org]
Sent: Friday, August 21, 2009 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 allow generics, etc. right from the start. We also didn't
feel like we had to convert everything in one fell swoop, either, as that
will break many existing patches.
On Aug 20, 2009, at 4:29 PM, Uwe Schindler wrote:
It would *not* break apps without generics, if the "upper" type is the same
(which is easily fulfilled by my example with the AttributeSource). The
whole 1.5 Java Collection API uses generics and 1.4 programs still run.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
_____
From: Shai Erera [mailto:serera@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., 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-compat later on.
Shai
On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <ma...@gmail.com> wrote:
Michael McCandless wrote:
> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
> include new features too.
>
> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
> but I can't remember it nor find it now...
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
I thought the motivation was to provide a clean upgrade path with the
deprecations - you move to 2.9 and move from all the deprecated methods
- then you move to 3.0 and your good with no deprecations. I'd guess the
worry is that new features in 3.0 would add new deprecations and its not
quite so clean?
Personally, I think thats fine though. New deprecations will come in 3.1
anyway. You can still move everything in 2.9, and then move to 3.0 - so
what if something else is now deprecated? You can move again or wait for
3.9 to move ...
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using
Solr/Lucene:
http://www.lucidimagination.com/search
Re: Finishing Lucene 2.9
Posted by Grant Ingersoll <gs...@apache.org>.
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 allow generics, etc. right from the start.
We also didn't feel like we had to convert everything in one fell
swoop, either, as that will break many existing patches.
On Aug 20, 2009, at 4:29 PM, Uwe Schindler wrote:
> It would *not* break apps without generics, if the „upper” type is
> the same (which is easily fulfilled by my example with the
> AttributeSource). The whole 1.5 Java Collection API uses generics
> and 1.4 programs still run.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> From: Shai Erera [mailto:serera@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., 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-compat later on.
>
> Shai
>
> On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <ma...@gmail.com>
> wrote:
> Michael McCandless wrote:
> > On Wed, Aug 19, 2009 at 6:21 PM, Mark
> Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
> > include new features too.
> >
> > I thought I had read a motivation for the 1.9 -> 2.0 fast
> turnaround,
> > but I can't remember it nor find it now...
> >
> > Mike
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
> I thought the motivation was to provide a clean upgrade path with the
> deprecations - you move to 2.9 and move from all the deprecated
> methods
> - then you move to 3.0 and your good with no deprecations. I'd guess
> the
> worry is that new features in 3.0 would add new deprecations and its
> not
> quite so clean?
>
> Personally, I think thats fine though. New deprecations will come in
> 3.1
> anyway. You can still move everything in 2.9, and then move to 3.0 -
> so
> what if something else is now deprecated? You can move again or wait
> for
> 3.9 to move ...
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)
using Solr/Lucene:
http://www.lucidimagination.com/search
RE: Finishing Lucene 2.9
Posted by Uwe Schindler <uw...@thetaphi.de>.
It would *not* break apps without generics, if the "upper" type is the same
(which is easily fulfilled by my example with the AttributeSource). The
whole 1.5 Java Collection API uses generics and 1.4 programs still run.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
_____
From: Shai Erera [mailto:serera@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., 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-compat later on.
Shai
On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <ma...@gmail.com> wrote:
Michael McCandless wrote:
> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
> include new features too.
>
> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
> but I can't remember it nor find it now...
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
I thought the motivation was to provide a clean upgrade path with the
deprecations - you move to 2.9 and move from all the deprecated methods
- then you move to 3.0 and your good with no deprecations. I'd guess the
worry is that new features in 3.0 would add new deprecations and its not
quite so clean?
Personally, I think thats fine though. New deprecations will come in 3.1
anyway. You can still move everything in 2.9, and then move to 3.0 - so
what if something else is now deprecated? You can move again or wait for
3.9 to move ...
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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 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-compat later on.
>
> Shai
>
> On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <markrmiller@gmail.com
> <ma...@gmail.com>> wrote:
>
> Michael McCandless wrote:
> > On Wed, Aug 19, 2009 at 6:21 PM, Mark
> Miller<markrmiller@gmail.com <ma...@gmail.com>> 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, take out time doing the 3.0 release, ie let it
> > include new features too.
> >
> > I thought I had read a motivation for the 1.9 -> 2.0 fast
> turnaround,
> > but I can't remember it nor find it now...
> >
> > Mike
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
> >
> >
> I thought the motivation was to provide a clean upgrade path with the
> deprecations - you move to 2.9 and move from all the deprecated
> methods
> - then you move to 3.0 and your good with no deprecations. I'd
> guess the
> worry is that new features in 3.0 would add new deprecations and
> its not
> quite so clean?
>
> Personally, I think thats fine though. New deprecations will come
> in 3.1
> anyway. You can still move everything in 2.9, and then move to 3.0
> - so
> what if something else is now deprecated? You can move again or
> wait for
> 3.9 to move ...
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> For additional commands, e-mail: java-dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
>
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Shai Erera <se...@gmail.com>.
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-compat later on.
Shai
On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <ma...@gmail.com> wrote:
> Michael McCandless wrote:
> > On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com>
> 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, take out time doing the 3.0 release, ie let it
> > include new features too.
> >
> > I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
> > but I can't remember it nor find it now...
> >
> > Mike
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
> I thought the motivation was to provide a clean upgrade path with the
> deprecations - you move to 2.9 and move from all the deprecated methods
> - then you move to 3.0 and your good with no deprecations. I'd guess the
> worry is that new features in 3.0 would add new deprecations and its not
> quite so clean?
>
> Personally, I think thats fine though. New deprecations will come in 3.1
> anyway. You can still move everything in 2.9, and then move to 3.0 - so
> what if something else is now deprecated? You can move again or wait for
> 3.9 to move ...
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
Michael McCandless wrote:
> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
> include new features too.
>
> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
> but I can't remember it nor find it now...
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
I thought the motivation was to provide a clean upgrade path with the
deprecations - you move to 2.9 and move from all the deprecated methods
- then you move to 3.0 and your good with no deprecations. I'd guess the
worry is that new features in 3.0 would add new deprecations and its not
quite so clean?
Personally, I think thats fine though. New deprecations will come in 3.1
anyway. You can still move everything in 2.9, and then move to 3.0 - so
what if something else is now deprecated? You can move again or wait for
3.9 to move ...
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<ma...@gmail.com> 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, take out time doing the 3.0 release, ie let it
include new features too.
I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
but I can't remember it nor find it now...
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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/javadoc/packaging etc.
>>
>> 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 we lock down trunk for a
>> while, to force people to concentrate on *this* release. Otherwise we
>> divide our limited forces into two - those working on release, and those
>> working on trunk and beyond. We can kind of enforce this by making the
>> release branch last minute I think.
>>
>
> I think 3.0 is a little bit special: We move to Java 1.5, so in my opinion,
> we should not only remove deprecations, but also add Generics and remove
> StringBuffer and so on. I have some "patches" for that available, e.g. the
> casting currently needed for the Attributes API can be more elegantly solved
> by using generics (something like "T addAttribute(Class<T extends
> Attribute>)"). If we do not add generics to the public API in 3.0, we have
> to wait one major release longer to add them.
>
> To get the 3.0 release shortly after 2.9, we should branch now, that the
> generics commits could be done early. I would also help to do this (at least
> for the parts I was working on the last time).
>
>
I forgot about this oddity. Its so weird. Its like we are doing two
releases on top of each other - it just seems confusing.
Apache Lucene announces 2.9 - a lot of hard work and sweat - move to it
and five minutes later
Apache Lucene announces 3.0 - very little work, but different and
improved (generified anyway). No new features in 3.0. Hold the applause.
Now move to it.
I vote to make this more sane :)
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: Finishing Lucene 2.9
Posted by Uwe Schindler <uw...@thetaphi.de>.
> 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 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 we lock down trunk for a
> while, to force people to concentrate on *this* release. Otherwise we
> divide our limited forces into two - those working on release, and those
> working on trunk and beyond. We can kind of enforce this by making the
> release branch last minute I think.
I think 3.0 is a little bit special: We move to Java 1.5, so in my opinion,
we should not only remove deprecations, but also add Generics and remove
StringBuffer and so on. I have some "patches" for that available, e.g. the
casting currently needed for the Attributes API can be more elegantly solved
by using generics (something like "T addAttribute(Class<T extends
Attribute>)"). If we do not add generics to the public API in 3.0, we have
to wait one major release longer to add them.
To get the 3.0 release shortly after 2.9, we should branch now, that the
generics commits could be done early. I would also help to do this (at least
for the parts I was working on the last time).
> 4. I suggest we offer an early release candidate type build (very soon)
> - nothing official, nothing signed - just something easier for our user
> community to test with if they are not very familiar with building a
> release off of trunk.
+1 Start the release process!
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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 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 we lock down trunk for a
while, to force people to concentrate on *this* release. Otherwise we
divide our limited forces into two - those working on release, and those
working on trunk and beyond. We can kind of enforce this by making the
release branch last minute I think.
4. I suggest we offer an early release candidate type build (very soon)
- nothing official, nothing signed - just something easier for our user
community to test with if they are not very familiar with building a
release off of trunk.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael McCandless <lu...@mikemccandless.com>.
Yay!
Mike
On Tue, Aug 18, 2009 at 3:26 PM, Mark Miller<ma...@gmail.com> 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 unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Mark Miller <ma...@gmail.com>.
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: Finishing Lucene 2.9
Posted by Uwe Schindler <uw...@thetaphi.de>.
> 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 slated to replace the old, it
> seems this one is no longer the blocker issue it appeared to be? Would
> be great to get info either way.
I would also set this to 3.1 for the same reason, I will update the issue
soon. As we do not deprecate the old query parser now, it would have been
good to have the configureable numeric fields in the old wuery parser, but I
think this is too late. We should add a comment in Javadocs, that the old
(and also new) query parser do not work automatically with
NumericRangeQuery, and that you should override getRangeQuery() and do a
case-switch on the field name. I will do this later this day.
> LUCENE-1792 new QueryParser fails to set AUTO REWRITE for multi-term
> queries
>
> Our other problem child. Hows it looking on finishing this? I see
> Michael is still waiting on an apply-able patch. Looks like this and
> 1768 are the only possible hold ups at the moment.
I think Luis is working on that.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Finishing Lucene 2.9
Posted by Michael Busch <bu...@gmail.com>.
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 of the week if at all possible. It
> hasn't been a bad thing that wrap up has taken this long – its given
> our brave trunk user community more time to flag and test the issues
> we have been cramming in lately – but it seems to me its about time to
> start a real testing period on something more stable. If we can get
> down to 0 issues by the end of the week, I think we will be ready to
> make the 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 slated to replace the old, it
> seems this one is no longer the blocker issue it appeared to be? Would
> be great to get info either way.
I also thing we should defer this one.
>
> LUCENE-1791 Enhance QueryUtils and CheckHIts to wrap everything they
> check in MultiReader/MultiSearcher
>
> I believe has is ready to commit this one – essentially done.
>
> LUCENE-1692 Contrib analyzers need tests
>
> Robert is about to commit this one – essentially done.
>
> LUCENE-1813 Add option to ReverseStringFilter to mark reversed tokens
>
> Looks like there is a bit left to do, but that this will likely be
> done this week.
>
> LUCENE-1792 new QueryParser fails to set AUTO REWRITE for multi-term
> queries
>
> Our other problem child. Hows it looking on finishing this? I see
> Michael is still waiting on an apply-able patch. Looks like this and
> 1768 are the only possible hold ups at the moment.
>
I'm optimistic that we can resolve this within the next couple of days.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org