Re: I'm not sure if there is a coding difference between the C# stuff and
the other directory stuff.
There are a few minor code changes in the new branch vs the C# branch, but
those are things like framework target, copyright notices, etc.. I didn't
change code significantly, and unit tests still
Yes, sorry -- I didn't mean to conflate the two issues.
'var' is just syntactic sugar. I'm more concerned with the framework support
issue, which is not directly related to the use of var, but is tied in with
the discussion.
Thanks,
Troy
On Mon, May 9, 2011 at 1:18 PM, Digy digyd...@gmail.com
* but the bug existed in older *
On Mon, May 9, 2011 at 4:28 PM, Michael Herndon mhern...@wickedsoftware.net
wrote:
The government tends to work in this fashion of wanting security and
critical bug updates, but are generally unwilling to upgrade underlying
platform to a newer major version.
What about
For 2.9.4:
[-1] No, .Net Framework 2.0 should remain our target platform. Backwards
compatibility is more important than new features and performance.
AND
For 2.9.4g:
[+1] - Yes, move forward to the latest .Net Framework version, and drop
support for 2.0 completely. New features and
Before 2.9.4g, I would surely say drop support for 2.0 completely. But now we
have two versions(2.9.4 2.9.4g) and one can continue to support 2.0 till its
death (2.9.4g may be used as base for future versions, but this is not true for
2.9.4)
DIGY
-Original Message-
From: Troy Howard
Michael,
That worked!
I'm in the process of making a wiki page for the event now.
Thanks,
Troy
On Mon, May 9, 2011 at 1:38 PM, Michael Herndon
mhern...@wickedsoftware.net wrote:
log out and log back in and verify permission changes.
On Mon, May 9, 2011 at 4:22 PM, Troy Howard
I chose the name 2.9.4g, since 2.9.5 may give a feeling of lucene.java 2.9.5
exists.
2.9.4g is somewhere between 2.9.4 3.0.3(more close to 3.0.3)
DIGY
-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com]
Sent: Monday, May 09, 2011 11:54 PM
To:
+1
-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com]
Sent: Monday, May 09, 2011 4:05 PM
To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net
2.9.4
All,
Please cast your
That makes sense, however my suggestion of using 2.9.5 is for the same
purpose. Since the code base is now diverging from the Java library,
it makes sense that the version numbers would diverge as well. The
fact that there is no Java version 2.9.5 will make that Lucene.Net
version stand out as
Indeed... 2.9.4g it is!
G for Generics should be easy to remember.
On Mon, May 9, 2011 at 2:27 PM, Digy digyd...@gmail.com wrote:
It is used already.
https://issues.apache.org/jira/browse/LUCENE/fixforversion/12315914
DIGY
-Original Message-
From: Troy Howard
+1
PS: If you are supporting .NET 3.5 then you get .NET 2.0 support anyway, you
just have to bin-deploy the .NET 3.5 dependencies (System.Core, etc) since they
are all the same CLR
Aaron Powell
MVP - Internet Explorer (Development) | Umbraco Core Team Member | FunnelWeb
Team Member
My goal with moving forward to .Net 4.0 specifically, is that with 4.0
there are major improvements to the .NET GC, which we have already
found in our company's testing, improves Lucene.Net's memory
management and overall speed significantly. This is without any code
changes, just compiling for
That only works if you are *allowed* to deploy a new or updated .NET framework
on the target system, which is not always true.
But the problem is not really about deployment it is really more for those of
us who must compile from source and who are not permitted to upgrade our
development
Here's the wiki page:
https://cwiki.apache.org/confluence/x/Go6OAQ
Thanks,
Troy
On Mon, May 9, 2011 at 1:59 PM, Troy Howard thowar...@gmail.com wrote:
Michael,
That worked!
I'm in the process of making a wiki page for the event now.
Thanks,
Troy
On Mon, May 9, 2011 at 1:38 PM,
14 matches
Mail list logo
