lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Lucene's default settings & back compatibility
Date Wed, 20 May 2009 20:39:30 GMT
Shai Erera wrote:
>     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).
Thats a good point - eventually you have to face the piper and move or 
not. But its kind of nicely isolated to a point every couple years (we 
have talked about releasing more often in the past, and I hope that 
comes up again). You can ride bug fixes for a whole version release (a 
couple years). With the new way, you can get the first bug fix release, 
but then you will quickly be left out of new bug fixes until you update 
your code.
> 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.
You have both options today though right?
> 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?
It would be nice to know these types of things more conclusively.
> 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).
We are not always so in control of our time though :) The new 
TokenStream API is a bit confusing - I'd have held off upgrading. I 
think there is even Lucene code (tests?) that uses the old API. There is 
tons of test code using deprecated API's. I don't think most people move 
immediately, because most people are lazy ;) Or time constrained. I'm 
not fully in either camp though. Frankly, I'd argue either side and hope 
smarter people figure out the right choice ;)
> 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 :)
Thats not really the style Lucene has taken in the past :)
> Shai

- Mark

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message