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
