: Of course, if we change the semantics of , we can remove
: the deprecated code in 5.0 because the behavior changed and it's fine if
: users don't pay attention since nothing breaks in their apps. I will handle
exactly.
-Hoss
http://www.lucidworks.com/
---
OK, I agree I didn't have XML APIs in mind when I wrote that. So if we
change that API such that users *must* migrate (because e.g. we add a new
mandatory parameter), then that's fine not to keep old code. But if users'
apps silently use other settings just because they didn't upgrade their XML
fil
: Maybe we can have a new parameter to affect both
: newly flushed and newly merged segments (this will be translated into
: respective IWC and MP settings), and we make affect IWC
: only? I know this is a slight change to back-compat, but it's not a serious
: change as in user indexes will stil
Thanks Hoss for the detailed reply!
About , I understand the simplification this brings to
regular users, but I also think we should protect such users from making
silly mistakes, ONLY because they don't have deep understanding of the
underlying stuff. Packing 20GB segments in a compound file will
: I understand that this might seem as a simplification to users, where they
: set this value once and it controls both places, but I think it's bad.
: First, because if you set , you basically *always* end up
: w/ CFS, even if you intend that to apply to only newly flushed segments. In
: order to
