lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: Lucene's default settings & back compatibility
Date Wed, 20 May 2009 20:31:10 GMT
>
> When the flood gates open, and code is rolling all over the place,
> upgrading Lucene becomes less of a buffet and more of a pain in the a**
>

I slightly disagree with that. If I'm a 2.2 user and I silently upgraded to
2.4, 2.4.1 and 2.9 I will have loads of work to do when I come to upgrade to
3.0 (because for me, 3.0 is exactly as if the gates just opened).

The way I see it, I *should* fully upgrade to 2.4, in order to spare me the
work when I upgrade to 3.0. By the time 3.0 is out I may have so many
changes to handle that I might re-consider upgrading at all.
Today, I believe users are not so silently upgrading, but prepare themselves
for the future. Even if they don't take advantage of new defaults, they at
least get rid of deprecated code because that's for sure will change in the
next major release, so why wait?

A personal example - I wrote an Analyzer which includes lots of code (lots
of TokenFilters, Tokenizers etc.). Then I see that the whole TokenStream API
is deprecated and will be replaced. Do I have to change the code right-away
- NO. But I will do it because why wait for 3.0? When 3.0 is out I will have
much more things to do. I prefer incremental changes to my code, then
complete overhaul (better testing-wise also) (this is a true example, not
something I'm making up).

It is true that currently you can decide when you want to make revisions to
your code, but in reality I wonder how common it is.

One way to check it (other than doing a survey) is to change the policy and
see how many scream at us :)

Shai

On Wed, May 20, 2009 at 11:17 PM, Mark Miller <markrmiller@gmail.com> wrote:

>
>
>  Earwin Burrfoot wrote:
>> See, you upgrade either for new features, or for performance
>>
>> improvements. You have to write code for former, and you have to write
>>
>> code for the latter (because by default most of them are off).
>> Mark Miller:
>>
>>
>>> If you have upgraded Lucene over the years and you never touched code to
>>> tweak performance, you still got fantastic performance improvements. You
>>> just didn't get them all.
>>>
>>>
>> If you never touched the code over the years, your project is probably
>> already dead
>>
> Does't alter the point though. You claimed that you missed the performance
> benefits if you upgraded Lucene, but you did not; regardless of if your
> project is dead, Lucene, with defaults, has seen large performance
> improvements over the years.
>
> Many healthy projects have components of working code that work as needed
> and are rarely touched. Should we be bending over backwards so that those
> users can plug in a speed improvement a year or two down the line with no
> hassle? Thats a different argument - one thats happened many times over the
> years on this list. But users did see fantastic performance improvements
> without changing code regardless.
>
> To the point of having to change a lot of code - right now you can easily
> pick and choose new features, defaults, and usually, upgrading lucene is
> fairly leisurely. When the flood gates open, and code is rolling all over
> the place, upgrading Lucene becomes less of a buffet and more of a pain in
> the a**. That said, I see the points and value of relaxing the back compat
> policy as well. Its been discussed a lot in the past, and it has been eased
> in the past.
>
> --
> - 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
>
>

Mime
View raw message