lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prescott Nasser <>
Subject RE: Long-terms plans for supporting .NET 3.5
Date Fri, 11 Jan 2013 23:58:49 GMT
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:
> To:
> There was an email thread last week (Lucene v3.6
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message