On 4/21/10 11:25 AM, Michael McCandless wrote:
Trying to summarize what we seem to be roughly converging to, here:
* Up front: consolidate all Solr core, Lucene core, contrib
analyzers into one place (contrib/analyzers). Don't use Version
in there; instead, the released JAR is versioned. The app picks
its required version compatibility by picking the right analyzers
JAR to use.
What about api back breaks? Seems like an issue when trunk will be free
to break. How will you know what versions of analyzers can be used by
which versions of Lucene? Just a readme? Are their any guarantee's? How
will I know when I get locked out of upgrading Lucene because of the
analyzer version choice I made?
* Switch to two active branches for ongoing development (stable&
trunk) -- stable gets features/bug fixes that are low risk / don't
change (too many?) APIs. We make minor releases off of stable
(3.0, 3.1, 3.2, and possibly also bug-fix only .Z release like
3.0.1), while trunk has ongoing non-back-compatible changes.
Development should be active on both.
* Maybe release 3.1 today, by branching off trunk before flex
landed, maybe minus a few changes. This would be the start of the
stable branch for 3.x releases, and trunk becomes experimental.
* Index compatibility on a major release falls into 3 levels:
- Level 1: index is read/written "live" (this is what we have
today).
- Level 2: we provide a migration tool (this is what we'd do for
the flex changes), to carry the index forward.
- Level 3: app must re-index.
I would expect level 3 to be very rare.... (it's never happened so
far!).
Does this sound right? Objections?
Mike
Sounds good to me - but I still think it should include that stable is
still the default dev branch - with trunk used for cases where it is needed.
- Mark
On Mon, Apr 19, 2010 at 4:37 AM, Shai Erera<ser...@gmail.com> wrote:
The 'unless' part is good and in place IMO. Certainly, if sometimes in the
future Lucene moves away from segmented indexing approach into something
else, I wouldn't expect a migration tool to be introduced. So overhauling
index file format might be ok to go w/o any migration tool introduced.
But I think we tend to take it as a "all or nothing" deal. When the index
file format changed (and Mike can correct me if I'm wrong), it usually
didn't introduce such overhauling changes. For example, "flex scoring" - we
can say that a flex-scoring index should read older indexes, and if one did
not want to take advantage of that feature, one should not reindex just
because he upgrade to Lucene 4.0, for other reasons. I believe that should
be relatively easy to support.
And I think that people understand that they cannot take advantage of a new
feature until they reindex (features like flex-scoring, numeric queries
etc.) -- I just think we shouldn't *force* them to reindex just because the
indexing code now 'expects' those files/terms to be in place for regular
indexing behavior (unrelated to those advanced features).
I'm +1 for that proposal.
Shai
On Mon, Apr 19, 2010 at 11:28 AM, Doron Cohen<cdor...@gmail.com> wrote:
Late joining... could we agree on an "intention" to provide an index
migration tool when/if format back comp. has to be broken? It is not clear
to me that this was agreed... So here is a suggestion for a revised index
format backwards compatibility policy:
Starting release 4.0, Lucene has a limited file formats back-compatibility
between major versions, falling into one of the three possible levels:
(Level 1) When possible, Version X is would be able to read indexes
generated by any X-1 version after and including version X-1.0. (Level 2) If
version X cannot read indexes of version X-1, the release of version X would
be accompanied by a tool for migrating indexes from X-1 to X, unless (Level
3) the nature of the specific change does not allow for the development of
such a migration tool. For the exact level of file back compatibility of a
release see the specific release notes.
Not sure if the "unless" part (no. 3) would ever materialize, but I think
it provides a required freedom.
Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
