On Sat, Aug 2, 2014 at 12:41 PM, Shai Erera <ser...@gmail.com> wrote: > Another proposal that I made on LUCENE-5859 is to get rid of Version (for > Analyzers) and follow the solution we have with Codecs. If an Analyzer > changes its runtime behavior, and e.g not marked @experimental, it can > create a Foo49Analyzer with the new behavior. That way, apps are still safe > when they upgrade, since their Foo45Analyzer still exists (but deprecated). > And they can always copy a Foo45Analyzer when they upgrade to Lucene 6.0 > where it no longer exists... with this approach, there's no single version > across the app - it just uses the specific Analyzer impls.
But the usability here would be really bad. For codecs there isn't much a better thing to name it anyway, and codecs are super-expert to change. For analyzers usability is paramount. I do think its ok to name _backwards_ compat tokenizer/tokenfilter classes this way. In fact its already this way in trunk for any back compat *actually doing something*: Lucene43NgramTokenizer, Lucene47WordDelimiterFilter. The Version parameters are just for show, not doing anything! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
