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 files (and old tags are ignored), that's not good.
Of course, if we change the semantics of <useCompoundFile>, 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 that under the same issue. Shai On Mon, Aug 11, 2014 at 7:55 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : Maybe we can have a new parameter <alwaysUseCompoundFile> to affect both > : newly flushed and newly merged segments (this will be translated into > : respective IWC and MP settings), and we make <useCompoundFile> 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 still work as they did, only huge merged > : segments won't be packed in a CFS. So if anyone asks, we just tell them > to > : migrate to the new API. > > I think that's fine ... but i also think it's fine to make a clean break > of it, and document in CHANGES.txt's upgrade section "<useCompoundFile> no > longer affects the MergePolicy, it only impacts IndexWriterConfig, because > that makes the most sense by default and most users on upgrade should be > better off in this situation -- if you really want to *always* use > compound files, add the following settings to your <mergePolicy/> > config..." > > Happy to let you make that call -- no strong opinion about it. > > : As for keeping code in for as long as we can ... I have a problem with > : that. It's like we try to "educate" users about the best use of Solr, > : through WARN messages, but then don't make them do the actual cut ever, > : unless it gets in the developers' way. I'd prefer that we treat the XML > : files like any other API -- we deprecate and remove in the next major > : release. Users have all the time through 4.x to get used to the new API. > : When 5.0 is out, they have to make the cut, and since we also document > that > : in the migration guide, it should be enough, no? > > There's a subtle but important distinction though between "Java APIs" and > "XML APIs" -- which is why i tend to err on the side of leaving in support > for things as long as possible when dealing with XML parsing. > > in both cases,you can add a deprecation message (from the compiler, > or a warning message logged by the config file parsing code) but the > question is what happens if they ignore or don't notice those warnings and > keeps upgrading -- or does a leap frog upgrade (ie: goes straight from 4.5 > to 5.0, and you deprecated soemthing in 4.6) > > if you rip out that Java API in 5.0, a user who blindly upgrades will get > a hard failure right up front at compilation and knows immediately that > there is a problem and they have to consult the upgrade/migration docs. > > on the xml side though ... a user who does a leap frog upgrade straight > from 4.5 to 5.0 (or didn't notice the warnings logged by 4.6) will have no > idea that their config is now being ignored -- unless of course there is > special logic in the 5.0 code to check for it, bug if you're leaving that > in there, then why not leave in code to try and be backcompat as well? > > > but like i said .. it's a fine line, and a judegement call -- there > hasn't really been an explicit "this is what we always do". in some > cases the impact on users is minor but the burden on developers is heavy, > so it's easy to make one choice ... in other cases the impact on users > can be significant, so a little extra effort is put into backcompat, or at > least keeping an explicit check & hard failure message in the code beyond > the next X.0 release. > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
