Introduce Version in more places long before 4.0 [LUCENE-2305]

[asfimport]

We need to introduce Version in as many places as we can (wherever it makes sense of course), and preferably long before 4.0 (or shall I say 3.9?) is out. That way, we can have a bunch of deprecated API now, that will be gone in 4.0, rather than doing it one class at a time and never finish :).

The purpose is to introduce Version wherever it is mandatory now, and also in places where we think it might be useful in the future (like most of our Analyzers, configured classes and configuration classes).

I marked this issue for 3.1, though I don't expect it to end in 3.1. I still think it will be done one step at a time, perhaps for cluster of classes together. But on the other hand I don't want to mark it for 4.0.0 because that needs to be resolved much sooner. So if I had a 3.9 version defined, I'd mark it for 3.9. We can do several commits in one issue right? So this one can live for a while in JIRA, while we gradually convert more and more classes.

The first candidate is InstantiatedIndexWriter which probably should take an IndexWriterConfig. While I converted the code to use IWC, I've noticed Instantiated defaults its maxFieldLength to the current default (10,000) which is deprecated. I couldn't change it for back-compat reasons. But we can upgrade it to accept IWC, and set to unlimited if the version is onOrAfter 3.1, otherwise stay w/ the deprecated default.

if it's acceptable to have several commits in one issue, I can start w/ Instantiated, post a patch and then we can continue to more classes.

---

Migrated from LUCENE-2305 by Shai Erera (@shaie), resolved Jan 12 2013

[asfimport]

Shai Erera (@shaie) (migrated from JIRA)

While working on #3396, I've noticed these two lines in MP:

  /* TODO 3.0: change this default to true */
  protected boolean calibrateSizeByDeletes = false;

Which were left out when we upgraded to 3.0. I guess MP just needs a Version, and then we can change that parameter to true if Version is later than 3.1 (or when this change is out)?

[asfimport]

Michael McCandless (@mikemccand) (migrated from JIRA)

Sigh, yes, adding Version to MP makes sense.

[asfimport]

Mark Miller (@markrmiller) (migrated from JIRA)

Hmm - if I remember right, this is one I brought up before and you said you no longer felt it really made sense to default to true Mike?

[asfimport]

Michael McCandless (@mikemccand) (migrated from JIRA)

Hmm... I think true is likely the better default (since it will tend, more, to merge segments that have many deletes)?

I had said leave it as false because we missed this TODO in 3.0.

But... if we add Version to MP (I think that makes sense) then I think we should flip the default?

[asfimport]

Mark Miller (@markrmiller) (migrated from JIRA)

Ah, yes - I didnt remember your comment right:

We could make the change under Version? (Change to true, starting in 3.1).

Or maybe not make the change. If set to true, we use pct deletion on
a segment to reduce its perceived size when selecting merges, which
generally causes segments with pending deletions to be merged away
sooner

Sounds like a good move.

[asfimport]

Shai Erera (@shaie) (migrated from JIRA)

4.0 is out long ago :).
And I don't think we need that issue if we want to add Version to more places.