You don't read what i wrote. Read it again.
On Sun, Aug 3, 2014 at 7:49 AM, Shai Erera <ser...@gmail.com> wrote: > Yes, I agree that Foo49Analyzer is an odd name. Better if it was named > FooAnalyzerWithNoApostrophe, and I'm fine if that Analyzer chose to name its > different versions like that. But in the absence of better naming ideas, I > proposed the Foo49Analyzer. > > If we already have such Analyzers, then we are in fact implementing that > approach, only didn't make that decision globally. So whether it's odd or > not, let's first agree if we are willing to have these analyzers in our code > base (i.e. w/ the back-compat support). If we do, we can let each Analyzer > decide on its naming. > > Analyzers aren't Codecs, I agree, and sticking the Lucene version in their > name is probably not the best thing to do, as the Lucene version is more > associated with the index format. But if a fixed Analyzer cannot come up w/ > a better name, I think the Lucene version there is not that horrible. > > And, it lets us easily remove Version.java. > > Shai > > > On Sun, Aug 3, 2014 at 2:43 PM, Robert Muir <rcm...@gmail.com> wrote: >> >> 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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
