lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: Long-terms plans for supporting .NET 3.5
Date Sun, 13 Jan 2013 01:47:48 GMT
I started working on porting 3.1 in another branch.  The porting work is
weird, and I would have no idea how to coordinate people working on the
same project as other developers.  There are so many classes that are
shared between namespaces, I think it would be difficult to do it without
doubling work.  Plus, who REALLY wants to do porting work? :)

There was talk in another thread where it was suggested that porting each
version of 3.x up to 4.0 would take too long...it does seem to take
_forever_ to get stuff released on this project.  So it really makes more
sense to jump right into the 4.0 code, for quite a few reasons.  I actually
think we should start over from scratch(ish).

We have a lot of things we want, we've discussed it many times, it involves
API changes and probably some design changes as well.  There has also been
expressed desire for supporting other platforms, like Windows Phone, RT or
Azure.  Supporting these would require pulling out common code into a core
library and having platform-specific ones for some of the features (ie.
File I/O).  We could pull out existing code from our current trunk, mainly
support classes and other things that haven't changed drastically.  I
already have some methods I've added to the Character support class I can
add, related to utf32 and surrogate characters.

We want API changes as well, which might be less daunting to implement if
we were writing 4.0 from a fresh perspective.  This would require active
organization and planning from every committer that wants to work on the
port, but ultimate, I think it might be a good way to do it.

I want to hear input from everyone on this and what would be the best way
to organize our group to make this project even more desirable.  Also, it's
nice to see the list getting a little bit more active than it was last half
of the year.  We've had a nice vacation.  Let's get back to work. :)


Thanks,
Christopher




On Fri, Jan 11, 2013 at 5:56 PM, Troy Howard <thoward37@gmail.com> wrote:

> 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