> 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. Afraid to ask which additional shackles Lucene bore in the past. I mean, 'what' has to be eased to produce policies we have right now? Joking, just really happy that something is seemingly going to change.
> 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** Really, I've got a major pain in the *s* upgrading from 2.4 to trunk (2.9). I upgraded to get per-segment collection and had to rewrite my nontrivial collectors - no back compat effort could save me from it. So, where to cast my weightless vote? :) > We still should balance the "cost" of non back-compatible changes with > the benefits. As Doug has said: "Lucene has a large install base. A > little effort towards back-compatibility on our part saves folks a lot > of effort." That's a good approach. Renaming a method, changing/adding some constructor parameters is really easy, you don't need to keep old things around. Doing deletes/norm updates through IndexWriter instead of IndexReader - that's more work, but it's not complex. Going from old Analyzer API to new one, or HitCollector -> Collector, that's where real pain starts, because API changed dramatically not only in its form, but in its meaning too. So a back-compat layer there is reasonable. -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
