Analysis API (like any other public API) definitely should not be broken within a major release.
I think we should also minimize the API surface area required of analysis by the indexer & query parser. Eg, indexer doesn't need to know about an analyzer -- instead, it should interact with an iterator that provides fields w/ a token stream (minus close/reset). Whether the field is a Reader, pre-created token stream, String, etc., not-analyzed, etc., should live outside of indexer... Mike On Wed, Apr 21, 2010 at 2:32 PM, Mark Miller <[email protected]> wrote: > On 4/21/10 2:28 PM, Robert Muir wrote: > > On Wed, Apr 21, 2010 at 2:20 PM, Mark Miller <[email protected]> wrote: >> >> 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? > > In my opinion the analysis API should not be backwards broken at least > within a major release... or else this could prevent someone from using > analyzers-4.2.jar with lucene-core-4.8.jar. > In general under this scheme we should be able to avoid backwards breaks > better I think (e.g. dont backport things to stable that backwards break). > > If you want analyzers to actually work across major releases that seems to > be more challenging, but maybe minimizing the interface between > analyzers<->queryparser and analyzers<->indexer as much as possible could > help. > > -- > Robert Muir > [email protected] > > That sounds good to me - I'm personally not very worried about back compat > over a major release either. > > - Mark > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
