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 <[email protected]> wrote: > I agree regarding framework versions. Lucene 4 == .NET 4 ... Simple. :) > > On Fri, Jan 11, 2013 at 3:58 PM, Prescott Nasser <[email protected] > >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: [email protected] > > > To: [email protected] > > > > > > 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 > > > > >
