I hear you. Would additional constructors that default to Lucene_48 be a better choice then?
-- Itamar Syn-Hershko http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer & Consultant Lucene.NET committer and PMC member On Thu, Nov 10, 2016 at 9:32 AM, Shad Storhaug <[email protected]> wrote: > I realize that - we wouldn't want to make them optional anyway because > that would not be CLS compliant (which we may never fully achieve, but > should probably try to minimize the impact for in case we eventually want > to go there). > > Besides, one of the "users" are the unit tests and they require the > parameter to be there in order to test the legacy code fully. Certainly the > parameter will also be needed for those who want to upgrade from 3.0.3 > without changing their index format right away. > > But I agree with you that the majority of the users could get a better > experience if there were overloads that didn't expect the LuceneVersion > everywhere. > > But then, this really all depends on what the next planned version to port > is. Imagine everyone switched to this parameterless overload that defaulted > to 4.8.0, then upgraded to 6.x with the same index - they would need to > touch every place in their code where the parameter is missing and call the > overload with 4.8.0 (assuming 6.x goes back at least 2 versions of backward > compatibility). The worst part is that since it is a piece of missing code, > it would be impossible to find all of those locations with a search, which > would make the process very manual and prone to error. Maybe it would be > better to leave it alone...? Certainly, this is the reason why using > Version_Current is obsolete. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Itamar Syn-Hershko > Sent: Thursday, November 10, 2016 2:12 PM > To: [email protected] > Subject: Re: Removing LuceneVersion.LUCENE_48 from external API? > > Yes, but that essentially means changing them methods signatures since > it's the first parameter and default arguments need to be last > > > -- > > Itamar Syn-Hershko > http://code972.com | @synhershko <https://twitter.com/synhershko> > Freelance Developer & Consultant Lucene.NET committer and PMC member > > On Wed, Nov 9, 2016 at 11:07 PM, Shad Storhaug <[email protected]> > wrote: > > > Itamar, > > > > I think for those rare cases, we should leave it in. But, it would be > > a good idea to add overloads that default them to the current version > > so most users get a streamlined experience. > > > > You mentioned that you were "removing" them, I hope that you meant > > that you are simply providing overloads that don't have them so they > > are not required. > > > > Thanks, > > Shad Storhaug (NightOwl888) > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > On Behalf Of Itamar Syn-Hershko > > Sent: Thursday, November 10, 2016 10:27 AM > > To: [email protected] > > Subject: Re: Removing LuceneVersion.LUCENE_48 from external API? > > > > It's a required argument for those methods - while I think it's too > > verbose there as well, at least it makes sense because they have many > > versions. We don't really need it because we only have one version, > > except from the rare cases backwards supporting indexes that are > > shared with Java code that maintains them. > > > > -- > > > > Itamar Syn-Hershko > > http://code972.com | @synhershko <https://twitter.com/synhershko> > > Freelance Developer & Consultant Lucene.NET committer and PMC member > > > > On Mon, Nov 7, 2016 at 6:02 AM, Wyatt Barnett > > <[email protected]> > > wrote: > > > > > I think making it an optional parameter sounds like a good idea on > > > the surface. How does the java library handle this? > > > > > > On Thu, Nov 3, 2016 at 3:39 PM Itamar Syn-Hershko > > > <[email protected]> > > > wrote: > > > > > > > Hey folks, > > > > > > > > I'm working on some demos, and one things that keeps popping up > > > > and to be frank gets quite annoying is the requirement to specify > > > > LuceneVersion.LUCENE_48 on all public APIs - opening a readers and > > > writers, > > > > analyzers, etc. > > > > > > > > Since we only have one version release, and that concept is not > > > > going to > > > be > > > > really useful anyway, what do you say we remove (or set a default > > > > value > > > for > > > > it) on all public facing APIs? > > > > > > > > Cheers, > > > > > > > > -- > > > > > > > > Itamar Syn-Hershko > > > > http://code972.com | @synhershko <https://twitter.com/synhershko> > > > > Freelance Developer & Consultant Lucene.NET committer and PMC > > > > member > > > > > > > > > >
