lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Irwin <pir...@feature23.com>
Subject Re: Windows RT / WP8 Version
Date Wed, 21 Aug 2013 14:11:55 GMT
I appreciate the idea of having it portable, but after going through most
of the code myself with catching it up to 4.3 (still much work to be done),
I can attest that it would be exceptionally difficult if not impossible to
maintain an even partial port to PCL in the same codebase. Take a look at
the Util.FST classes, or the Util.Packed classes, or any of the Codecs in
4.x to see what I'm talking about. I do not want to see Lucene.net get
stuck in the dark ages due to trying to achieve PCL compatibility.

If anyone is passionate about having a partial port of Lucene core to PCL
(because I do not believe you can achieve a full port), I suggest spinning
off a new project or keeping the source completely separate rather than
filling the Lucene.net code with a bunch of #if statements and thus making
it much more difficult for us to do line-by-line updates of the Java code
in the future.


On Wed, Aug 21, 2013 at 3:45 AM, Christopher Currens <
currens.chris@gmail.com> wrote:

> Prescott,
>
> You're right in regards to PCL and MonoTouch.  I have no idea what I was
> thinking.  I seem to recall a year or so ago when you ran into that issue.
>  I believe WP8 supports unsigned value types, so it may not be an issue if
> WP7 isn't explicitly supported.
>
> Stefan,
>
> I'm prepared for it being an arduous task.  Most of the challenges you've
> listed are addressed by using PCL, except for legacy technologies.  When it
> comes to unsupported platforms, I think often times the only options is to
> drop support for them when it comes to new code.  Like you mentioned, we
> don't really hit the support level that log4net does, we've already made
> the decision to not support .NET 3.5 in the 4.x versions of Lucene.
>
> I still think my biggest blocker against PCL is that it's not in
> Express....I'd like to keep support for Express editions instead of
> potentially blocking people from contributing.
>
> Thanks,
> Christopher
>
>
> On Tue, Aug 20, 2013 at 11:41 PM, Stefan Bodewig <bodewig@apache.org>
> wrote:
>
> > On 2013-08-21, Christopher Currens wrote:
> >
> > > I've been thinking lately of doing a real push to have Lucene.Net
> support
> > > more platforms, specifically Windows RT and Windows Phone 8.  There are
> > two
> > > ways I can think of doing it, and each has its own specific advantages
> > and
> > > disadvantages.
> >
> > One thing I can tell you is that the release process can easily become a
> > PITA either way.  At least if you want to extend it to platforms VS
> > cannot cross-compile to OOTB.
> >
> > I've been the release manager of the last log4net release and am
> > preparing to cut a new one, so memory is fresh.  log4net uses NAnt to
> > build and builds for several platforms from the same codebase with
> > defines (NET_4_0 and so on) controlling code-paths that need specific
> > platform or language features.
> >
> > For each additional platform you add the release manager must be able to
> > build for it - no matter which approach you take.  This might be trivial
> > for some platforms as VS supports them today but not for others (say
> > MonoTouch) or no longer tomorrow (say you still want to support .NET 2.0
> > when VS 2015 drops support for it).
> >
> > In log4net's case keeping around a virtual machine running XP that can
> > still build .NET 1.0 is the biggest hurdle.  As Lucene.NET doesn't
> > strive to support old platforms as long as log4net does, this may not be
> > as big of an issue.
> >
> > Of course we release sources, not binaries.  So you could say the RM
> > only builds the stock .NET stuff and people who want to have a version
> > for MonoTouch should build them from source - or you have different team
> > members contribute binaries for different platforms much like the HTTPd
> > project does.
> >
> > Stefan
> >
>

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