lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <thowar...@gmail.com>
Subject Re: Long-terms plans for supporting .NET 3.5
Date Sat, 12 Jan 2013 01:56:28 GMT
I agree regarding framework versions. Lucene 4 == .NET 4 ... Simple. :)

On Fri, Jan 11, 2013 at 3:58 PM, Prescott Nasser <geobmx540@hotmail.com>wrote:

> I'm on the same page with 3.x and 4.x supporting differing versions.
> For actual effort, where do we put it now? Do we get up to speed with 3.6
> quickly, then try to do the 4.x?
>
> > Date: Tue, 8 Jan 2013 10:27:04 -0800
> > Subject: Long-terms plans for supporting .NET 3.5
> > From: currens.chris@gmail.com
> > To: lucene-net-dev@lucene.apache.org
> >
> > There was an email thread last week (Lucene v3.6
> >
> http://mail-archives.apache.org/mod_mbox/lucenenet-dev/201301.mbox/browser
> )
> > where the feasibility of continuing support of .NET 3.5 was put into
> > question.  There are a few design patterns in Lucene 4.0 that would not
> > only be difficult to port to a .NET 3.5 target, but would also likely
> > complicate and clutter the code if trying to support both runtimes.
> >
> > The most used pattern deals with variance, which is only really supported
> > in .NET 4.0, and still differently than it is in Java.  Since generic
> > variance is not supported at all in .NET 3.5, it would make the porting
> > process a pain.
> >
> > Here is what I think, which I've already stated in that last email
> thread.
> >  I think that the port of Lucene 4.0 should be limited exclusively to
> .NET
> > 4.0 or greater frameworks.  I _do not_ think that we should drop .NET 3.5
> > support in the entire project.  I know that we have many people that
> still
> > rely on having a library targeting the 2.0 runtime.
> >
> > Instead, I think we should maintain two branches of lucene, similar to
> how
> > the java team does it, once for 3.x and one for 4.x.  The 3.x branch
> would
> > support both .NET 3.5 and .NET 4.0, whereas the 4.x branch would only
> > support .NET 4.0 or greater.  The 3.x branch would likely not be a
> perfect
> > port, since the later versions of lucene 3.x do start to include some
> > features that are difficult to translate into pre-.NET 4.0 targets.
> >
> > There were also requests in that thread to make the Lucene 4.0 port
> include
> > features like async/await API support, lambdas, and other .NET features.
>  I
> > think that those with busier schedules and/or less time to devote to the
> > project would be able to give valuable feedback when it comes to making
> > design decisions for the API.
> >
> > I think that this could be a good plan, and for those who are less than
> > thrilled to work on porting lucene 3.x, I'm willing to do the bulk of
> that
> > myself, if it's more desirable to work on the 4.0 branch.  I think it's a
> > relatively large investment, though, since the jump from where we are now
> > to lucene 4.0 is large enough that it will take a good amount of time and
> > effort from everyone to keep it going.
> >
> > Hopefully there are comments on this.  If there's not much discussion
> about
> > this in the next few days, I'm just going to set up a vote and go from
> > there.
> >
> >
> > Thanks,
> > Christopher
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message