On Tue, Apr 13, 2010 at 02:46:56PM -0400, Robert Muir wrote:
> Unlike other components in Lucene, Analyzers get hit the worst because any
> change is basically a break, and there's really not any other option besides
> Version to implement any backwards compatibility for them.
New class names would work, too.
I only mention that for the sake of completeness, though -- it's not a
suggestion.
> But things like index back compat seems kinda useless for analyzers anyway.
> If we improve them in nearly any way, you have to reindex with them to get
> the benefits.
I'm a little concerned about the issue DM Smith brought up: what happens when
you have separate applications within the same JVM which have built indexes
using separate versions of an Analyzer?
That use case is supported under the current regime, but I'm not sure whether
it would be with aggressively versioned Analyzer packages. If it's not, under
what circumstances does that matter?
> I'd love to hear elaborations of any thoughts you have on how this could
> work.
Well, for Lucy, I think we may have addressed this problem with the new back
compat policy we're auditioning with KS:
KinoSearch spins off stable forks into new namespaces periodically. As of
this release, the latest is "KinoSearch1", forked from version 0.165.
Users who require strong backwards compatibility should use a stable fork.
The main namespace, "KinoSearch", is an unstable development branch (as
hinted at by its version number). Superficial API changes are frequent.
Hard file format compatibility breaks which require reindexing are rare,
as we generally try to provide continuity across multiple releases, but
they happen every once in a while.
Essentially, we're free to break back compat within "Lucy" at any time, but
we're not able to break back compat within a stable fork like "Lucy1",
"Lucy2", etc. So what we'll probably do during normal development with
Analyzers is just change them and note the break in the Changes file.
I doubt such a policy would be an option for Lucene, though. I think you'd
have to go with separate jars for lucene-core and lucene-analyzers, possibly
on independent release schedules. You'd have to bundle the broken ones with
lucene-core until a major version break for bug compatibility, but the fixed
ones could be distributed via lucene-analyzers concurrently.
Hmm, I suppose that doesn't work with the convention that the only difference
between Lucene X.9 and Lucene Y.0 is the removal of deprecations. But if
anything is crying out for a rethink in the Lucene back compat policy, IMO
that's it: make major version breaks act like major version breaks and change
stuff that needs changin'.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
