> > 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 <markrmil...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
