[Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5

[Alexey Shcherbachev]

Hi,

First of all thank you for the new release 2.9.4. That makes me really
happy.

However, I noted that current binaries are build for .Net 4.0 framework
only, which is very inconvenient.
The reason is we have a hard requirement to use .Net3.5sp1.
We were going to build it manually as usual, but stumbled upon .Net 4.0
specific code (file CloseableThreadLocal.cs):

 private ThreadLocalWeakReference t = new ThreadLocalWeakReference();

For now we just replaced CloseableThreadLocal file with a version from
2.9.2, but still.

What is an official strategy of the Lucene.Net team about framework
versions?
Is there a chance that Lucene.Net will be released in future not only for
4.0, but for 3.5 too?

Kind Regards,
Alexey Shcherbachev
Rebel Search team
Skype: Leha-2304
Web: http://rebelsearch.net/

Re: [Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5

[Michael Herndon]

Hi Alexey,

I believe this version of Lucene.Net will be the last version that can be
compiled with the .NET 2.0 runtime which is what .NET 3.5 runs on. There
was a vote on supported runtime versions by the community this past year,
The community widely supported to drop .NET 2.0 runtime after the 2.9.4
release in favor of the .NET 4.0 runtime.

I also believe most of the committers will be focused on using generics
with the next version and possibly .NET 4.0 specific code. However, since
the code is open source, anyone can contribute branches that can be
compiled on the .NET 2.0 runtime. There is plenty of work and only a
handful of committers with a limited amount of time to work on the project
and there is a need for a narrow focus from the committers in order to move
the project forward with releases.  But we're more than open to discussing
what it would take to accomplish something like that if it has enough
support from the community if that is something that interests you or
anyone else reading this thread.

If you search the mailing list, DIGY has some instructions on how to
compile the 2.9.4 tag in a way that is compatible with .NET 2.0.

If I stumble across it or someone else knows the steps, it will re-posted
in this thread.  But it does have to do with commenting out the ThreadLocal
and uncommenting out another portion of the code.

- Michael



On Tue, Dec 6, 2011 at 7:42 AM, Alexey Shcherbachev 
ale...@renaissance-it.ru wrote:

 Hi,

 First of all thank you for the new release 2.9.4. That makes me really
 happy.

 However, I noted that current binaries are build for .Net 4.0 framework
 only, which is very inconvenient.
 The reason is we have a hard requirement to use .Net3.5sp1.
 We were going to build it manually as usual, but stumbled upon .Net 4.0
 specific code (file CloseableThreadLocal.cs):

  private ThreadLocalWeakReference t = new ThreadLocalWeakReference();

 For now we just replaced CloseableThreadLocal file with a version from
 2.9.2, but still.

 What is an official strategy of the Lucene.Net team about framework
 versions?
 Is there a chance that Lucene.Net will be released in future not only for
 4.0, but for 3.5 too?

 Kind Regards,
 Alexey Shcherbachev
 Rebel Search team
 Skype: Leha-2304
 Web: http://rebelsearch.net/

RE: [Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5

[Prescott Nasser]

From digy:

OK, here is the code that can be compiled against .NET 2.0
http://pastebin.com/k2f7JfPd

FYI, we believe there may be a memory leak related to this code ( not in this 
particular code though )

Sent from my Windows Phone

From: Michael Herndon
Sent: 12/6/2011 5:42 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5

Hi Alexey,

I believe this version of Lucene.Net will be the last version that can be
compiled with the .NET 2.0 runtime which is what .NET 3.5 runs on. There
was a vote on supported runtime versions by the community this past year,
The community widely supported to drop .NET 2.0 runtime after the 2.9.4
release in favor of the .NET 4.0 runtime.

I also believe most of the committers will be focused on using generics
with the next version and possibly .NET 4.0 specific code. However, since
the code is open source, anyone can contribute branches that can be
compiled on the .NET 2.0 runtime. There is plenty of work and only a
handful of committers with a limited amount of time to work on the project
and there is a need for a narrow focus from the committers in order to move
the project forward with releases.  But we're more than open to discussing
what it would take to accomplish something like that if it has enough
support from the community if that is something that interests you or
anyone else reading this thread.

If you search the mailing list, DIGY has some instructions on how to
compile the 2.9.4 tag in a way that is compatible with .NET 2.0.

If I stumble across it or someone else knows the steps, it will re-posted
in this thread.  But it does have to do with commenting out the ThreadLocal
and uncommenting out another portion of the code.

- Michael



On Tue, Dec 6, 2011 at 7:42 AM, Alexey Shcherbachev 
ale...@renaissance-it.ru wrote:

 Hi,

 First of all thank you for the new release 2.9.4. That makes me really
 happy.

 However, I noted that current binaries are build for .Net 4.0 framework
 only, which is very inconvenient.
 The reason is we have a hard requirement to use .Net3.5sp1.
 We were going to build it manually as usual, but stumbled upon .Net 4.0
 specific code (file CloseableThreadLocal.cs):

  private ThreadLocalWeakReference t = new ThreadLocalWeakReference();

 For now we just replaced CloseableThreadLocal file with a version from
 2.9.2, but still.

 What is an official strategy of the Lucene.Net team about framework
 versions?
 Is there a chance that Lucene.Net will be released in future not only for
 4.0, but for 3.5 too?

 Kind Regards,
 Alexey Shcherbachev
 Rebel Search team
 Skype: Leha-2304
 Web: http://rebelsearch.net/

[Lucene.Net] Apache Lucene.Net 2.9.4

[Prescott Nasser]

Hey All,

 

I'm happy to announce that we've released Lucene.Net 2.9.4. Check out the 
download page (http://incubator.apache.org/lucene.net/download.html) to get 
links to the source or binary files

 

~Prescott 

Re: [Lucene.Net] Apache Lucene.Net 2.9.4

[Stefan Bodewig]

On 2011-12-01, Prescott Nasser wrote:

 I'm happy to announce that we've released Lucene.Net 2.9.4.

Congratulations all.

It may be a good idea to flesh this out a bit with details of what has
changed and sending an announcement to announce@apache as well (you must
use your @apache.org address in order to get the mail through).

Stefan

RE: [Lucene.Net] Apache Lucene.Net 2.9.4

[Granroth, Neal V.]

Don't forget to tag the release in SubVersion.
The latest tag is RC3, and I assume that the trunk is the in-progress work on 
version 3.0.3.
- Neal

-Original Message-
From: Prescott Nasser [mailto:geobmx...@hotmail.com] 
Sent: Thursday, December 01, 2011 2:26 AM
To: lucene-net-...@incubator.apache.org; lucene-net-u...@incubator.apache.org
Subject: [Lucene.Net] Apache Lucene.Net 2.9.4


Hey All,

 

I'm happy to announce that we've released Lucene.Net 2.9.4. Check out the 
download page (http://incubator.apache.org/lucene.net/download.html) to get 
links to the source or binary files

 

~Prescott 

[Lucene.Net] 2.9.4 is a go for release

[Prescott Nasser]

Alright, we've passed the general voting gauntlet. Steps I see are:

 

1. Move the artifacts to the distribution place (not sure where or how yet)

2. NuGet for those who want it (if anyone is familiar with this, I have only 
used Nuget to get packages, not sure how to submit)

3. Update the website

 

~P

Re: [Lucene.Net] 2.9.4 is a go for release

[Stefan Bodewig]

On 2011-11-29, Prescott Nasser wrote:

 1. Move the artifacts to the distribution place (not sure where or how yet)

/www/www.apache.org/dist/incubator/lucene.net/

make sure all files and directories are owned by the group incubator and
group writable.  If you create new directories, set the sticky bit
(chmod 2775 dirname).

 3. Update the website

It may take up to an hour before the release is visible on the public
www.apache.org and several hours until all mirrors have picked up the
new files.  OTOH the website update will be immediate, so you better
hold back that part.

Stefan

RE: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

[Prescott Nasser]

I was just thinking about making some in depth documentation about this 
process. Doing it the first time has had its bumps. I'll get there.

Sent from my Windows Phone

From: Michael Herndon
Sent: 11/19/2011 11:38 PM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

+1 for wiki checklist  ticket for for build scripts to bundle all this
stuff for you.

On Sun, Nov 20, 2011 at 1:51 AM, Prescott Nasser geobmx...@hotmail.comwrote:

 Damn It - knew i was missing something

 Sent from my Windows Phone
 
 From: Stefan Bodewig
 Sent: 11/19/2011 10:34 PM
 To: lucene-net-...@incubator.apache.org
 Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

 On 2011-11-18, Prescott Nasser wrote:

  Third time is the charm:

 I'm afraid it is not.

  http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/

 Sigs and hashes are good.  Source zip and tag match except for the
 build/lib/doc dirs that are only inside the tag and which I agree is a
 good thing for now.

 LICENSE, NOTICE, DISCLAIMER look good in src.

 There is no NOTICE and no DISCLAIMER in the binary zip.  Has it been
 this way before?  If so I'm sorry I didn't catch it.  This is a blocker
 for me and probably would be for the other IPMC members as well.

 RAT is reasonably happy with the source tree.

 I can't give a +1 because of the missing files in the binary zip.  If
 you just recreated the binary with the two files added (and obviously
 resigned it and recalculated the hashes) I'd be happy to change that.

 Cheers

Stefan

RE: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

[Prescott Nasser]

I've updated the files - same location


 

~P



 From: bode...@apache.org
 To: lucene-net-...@incubator.apache.org
 Date: Sun, 20 Nov 2011 07:34:16 +0100
 Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

 On 2011-11-18, Prescott Nasser wrote:

  Third time is the charm:

 I'm afraid it is not.

  http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/

 Sigs and hashes are good. Source zip and tag match except for the
 build/lib/doc dirs that are only inside the tag and which I agree is a
 good thing for now.

 LICENSE, NOTICE, DISCLAIMER look good in src.

 There is no NOTICE and no DISCLAIMER in the binary zip. Has it been
 this way before? If so I'm sorry I didn't catch it. This is a blocker
 for me and probably would be for the other IPMC members as well.

 RAT is reasonably happy with the source tree.

 I can't give a +1 because of the missing files in the binary zip. If
 you just recreated the binary with the two files added (and obviously
 resigned it and recalculated the hashes) I'd be happy to change that.

 Cheers

 Stefan  

Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

[Stefan Bodewig]

On 2011-11-20, Prescott Nasser wrote:

 I've updated the files - same location

Thanks a lot!

Hashes and sigs are good.  All required legal files are in place.  src
zip still matches the tag (so I didn't have to re-run RAT)

+1

Stefan

RE: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

[Christopher Currens]

Some of the contrib stuff will be easier to port than others.  Some of it
relies on features the java character class has that .Net does not have.
If my memory serves me correctly, it has to do with the character map,
essentially java can tell you whig category it lives in, or Arabic,
Chinese, etc. .Net only gives you is letter, is digit, etc.

There are a few other difficulties in the hyphenation package, as well.  It
won't be totally painless.

I'm okay with not including it in the release and porting them later,
either for the next release, or if people request it.  I don't see any
reason we couldnt do it as a separate release, if community demand was high
enough.  So, I'm a +1. For a release as is.

+1

Sent from my phonograph, so there are likely some mistaken. ;)
On Nov 19, 2011 3:55 PM, Prescott Nasser geobmx...@hotmail.com wrote:


 I'm alright with them being out of partity if only because it seems like a
 lot of effort is moving away from 2.9.4. The core is all there



 If everyone else thinks otherwise, I'll start to update those, but
 otherwise, I'd like to close the chapter on 2.9.4 and put some effort into
 one of the other items people are working on.



 My hope is that 2.9.4 is quickly replaced with the next version - we have
 spent a lot of time sitting on this at this point



 ~P
 
  From: thowar...@gmail.com
  Date: Fri, 18 Nov 2011 18:17:20 -0800
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3
 
  So, I haven't looked at the artifacts, but I was just looking over the
  source code, and noticed something that we should probably discuss
  before voting on the artifacts.
 
  The files in Contrib\Analyzers are nowhere near in sync with 2.9.4...
  Not sure how old they are exactly, but they are very different from
  Java's 2.9.4 Contrib\Analyzers.
 
  This looks like a relatively small amount of work to update. Do we
  want to make a release without updating those to be 2.9.4 compatible?
 
  Are there any other things like this lurking in Contrib that haven't
  been updated?
 
  Thanks,
  Troy
 
  On Fri, Nov 18, 2011 at 1:33 AM, Prescott Nasser geobmx...@hotmail.com
 wrote:
  
   Third time is the charm:
  
  
  
   http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/
  
  
  
   I'll keep it open for 72 hours or so, then if all goes well, I'll make
 a vote to the general@incubator
  
  
  
   Thanks everyone for their help getting to this point.
  
  
  
   ~Prescott
  
  
  
   +1

RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Christopher Currens]

I build it using trunk/build/scripts/build.cmd all all - in the scripts
folder.  Make sure you've updated the folder.  That message is suspiciously
close to the message that would appear when it had the bug that would wipe
entire drives.
On Nov 19, 2011 4:25 PM, Prescott Nasser geobmx...@hotmail.com wrote:


 Hey Michael, I'm running build and getting the following error:




 build\scripts ./build

 ...
 The target 'all' does not exist in the project

 ...





 Should I be passing a command line argument to build all?






 
  Date: Mon, 31 Oct 2011 16:39:30 -0400
  From: mhern...@wickedsoftware.net
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
 
  @Troy,
 
  Now I don't feel as bad for my long e-mails. ;)
 
  -build scripts
 
  Except for building on mono or running NCover, the scripts work as
  intended. Also end users would need to install the required tools they
  intend to run with the build scripts. The scripts can be included, but it
  would be wise to include those caveats in a read-me somewhere.
 
  And there are ways to override the build scripts for user/custom build
  configurations. For those interested, post questions on a new thread.
 
  When you run the build scripts they should be including the xml files in
  the trunk/bin folder on successful builds. Please do let me know if that
  was not the case on your local machine if you used the scripts to build
 the
  binaries.
 
  -.snk
  The .snk in the lib folder is the original. When you create a new csproj,
  that is the file you use sign the binary with a strong key. The project
  defaults to creating a copy of the .snk file in its own folder. I can't
  remember if there is a way to just link it to only one file or not, but
  that was the default behavior.
 
  So to answer your question, if users/developers to create their own
 contrib
  projects or their own ci based upon a stable release tag and plan to use
  the same .snk, then it would be wise to include all of lib. If they are
  just building from a stable branch, you can exclude the .snk file as each
  project that uses it will have its own copy.
 
  - docs
  Generating both chm/html at the moment. I'll push the html version into
  source tonight for the website. and push a zip file with both the chm 
  static html site into a jira ticket. The chm is handy when you're in
  facility that is locked down and need to move around good deal of help
  files on a thumb drive.
 
  The xml files should be included. The xml files are only generated when
 you
  currently build a binary in Release mode for trunk  2.9.4g branch. So if
  you build the binaries and the xml files are not there, that is the most
  likely cause.
 
  Unless someone picks up the task of improving the overall xml doc
 comments
  between versions and generating them, most likely the documents will only
  be updated between releases.
 
  - Michael
 
 
 
 
 
  On Mon, Oct 31, 2011 at 3:41 PM, Troy Howard thowar...@gmail.com
 wrote:
 
   Prescott,
  
   Good job figuring out the signing and creating the release packages!
   It's non-trivial to figure out the first time from the docs, for sure.
   Sorry, I have been so busy this month that I wasn't able to provide
   help before you figured it out on your own. :)
  
   Some nitpicky details about the release packages:
  
   - Superfluous subfolders: There's an extra layer of subfolders named
   the same as the zip file which is unneeded
   - Root should be trunk all the time, even in the release packages,
   to keep relative pathing consistently rooted. So the binary release
   should have a bin subfolder at it's root to match the repo layout
   - XML doc files should be included in binary release. We have had
   users state a desire to have them for VS intellisense integration.
   This was an issue that came up during the last release package build
   cycle
   - Various notice files should be included in binary release as well
   - I don't know about the.SNK file from lib, maybe that should be in
   the source package, maybe not. I notice it's also in the core project
   folder. Which one does the project file reference?
   - .svn folder/files should be removed from source package
   - Empty subfolders should be left out (\build\vs2008 and \test\demo
   are the ones I noticed)
   - \docs are missing from source package as well
  
   Regarding docs, generally speaking, I think we should make a decision
   about what we want to provide and set a standard.
  
   Some considerations are:
   - XML doc files in binary package: Integrate with Visual Studio,
   providing a rich Intellisense experience, Generated at build time from
   source code. Where should they go in the folder structure to make it
   just work with VS from binary package?
   - Hosted HTML Single Version of the Truth vs HTML/CHM doc files in
   binary/source package: One one hand, we could only host docs

RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

I got lastest - so hopefully not :)

 

I think I'd cry a little bit if it got wiped.


 Date: Sat, 19 Nov 2011 17:55:05 -0800
 From: currens.ch...@gmail.com
 To: lucene-net-dev@lucene.apache.org
 Subject: RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

 I build it using trunk/build/scripts/build.cmd all all - in the scripts
 folder. Make sure you've updated the folder. That message is suspiciously
 close to the message that would appear when it had the bug that would wipe
 entire drives.
 On Nov 19, 2011 4:25 PM, Prescott Nasser geobmx...@hotmail.com wrote:

 
  Hey Michael, I'm running build and getting the following error:
 
 
 
 
  build\scripts ./build
 
  ...
  The target 'all' does not exist in the project
 
  ...
 
 
 
 
 
  Should I be passing a command line argument to build all?
 
 
 
 
 
 
  
   Date: Mon, 31 Oct 2011 16:39:30 -0400
   From: mhern...@wickedsoftware.net
   To: lucene-net-dev@lucene.apache.org
   Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
  
   @Troy,
  
   Now I don't feel as bad for my long e-mails. ;)
  
   -build scripts
  
   Except for building on mono or running NCover, the scripts work as
   intended. Also end users would need to install the required tools they
   intend to run with the build scripts. The scripts can be included, but it
   would be wise to include those caveats in a read-me somewhere.
  
   And there are ways to override the build scripts for user/custom build
   configurations. For those interested, post questions on a new thread.
  
   When you run the build scripts they should be including the xml files in
   the trunk/bin folder on successful builds. Please do let me know if that
   was not the case on your local machine if you used the scripts to build
  the
   binaries.
  
   -.snk
   The .snk in the lib folder is the original. When you create a new csproj,
   that is the file you use sign the binary with a strong key. The project
   defaults to creating a copy of the .snk file in its own folder. I can't
   remember if there is a way to just link it to only one file or not, but
   that was the default behavior.
  
   So to answer your question, if users/developers to create their own
  contrib
   projects or their own ci based upon a stable release tag and plan to use
   the same .snk, then it would be wise to include all of lib. If they are
   just building from a stable branch, you can exclude the .snk file as each
   project that uses it will have its own copy.
  
   - docs
   Generating both chm/html at the moment. I'll push the html version into
   source tonight for the website. and push a zip file with both the chm 
   static html site into a jira ticket. The chm is handy when you're in
   facility that is locked down and need to move around good deal of help
   files on a thumb drive.
  
   The xml files should be included. The xml files are only generated when
  you
   currently build a binary in Release mode for trunk  2.9.4g branch. So if
   you build the binaries and the xml files are not there, that is the most
   likely cause.
  
   Unless someone picks up the task of improving the overall xml doc
  comments
   between versions and generating them, most likely the documents will only
   be updated between releases.
  
   - Michael
  
  
  
  
  
   On Mon, Oct 31, 2011 at 3:41 PM, Troy Howard thowar...@gmail.com
  wrote:
  
Prescott,
   
Good job figuring out the signing and creating the release packages!
It's non-trivial to figure out the first time from the docs, for sure.
Sorry, I have been so busy this month that I wasn't able to provide
help before you figured it out on your own. :)
   
Some nitpicky details about the release packages:
   
- Superfluous subfolders: There's an extra layer of subfolders named
the same as the zip file which is unneeded
- Root should be trunk all the time, even in the release packages,
to keep relative pathing consistently rooted. So the binary release
should have a bin subfolder at it's root to match the repo layout
- XML doc files should be included in binary release. We have had
users state a desire to have them for VS intellisense integration.
This was an issue that came up during the last release package build
cycle
- Various notice files should be included in binary release as well
- I don't know about the.SNK file from lib, maybe that should be in
the source package, maybe not. I notice it's also in the core project
folder. Which one does the project file reference?
- .svn folder/files should be removed from source package
- Empty subfolders should be left out (\build\vs2008 and \test\demo
are the ones I noticed)
- \docs are missing from source package as well
   
Regarding docs, generally speaking, I think we should make a decision
about what we want to provide and set

Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

[Stefan Bodewig]

On 2011-11-18, Prescott Nasser wrote:

 Third time is the charm:

I'm afraid it is not.

 http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/

Sigs and hashes are good.  Source zip and tag match except for the
build/lib/doc dirs that are only inside the tag and which I agree is a
good thing for now.

LICENSE, NOTICE, DISCLAIMER look good in src.

There is no NOTICE and no DISCLAIMER in the binary zip.  Has it been
this way before?  If so I'm sorry I didn't catch it.  This is a blocker
for me and probably would be for the other IPMC members as well.

RAT is reasonably happy with the source tree.

I can't give a +1 because of the missing files in the binary zip.  If
you just recreated the binary with the two files added (and obviously
resigned it and recalculated the hashes) I'd be happy to change that.

Cheers

Stefan

Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

[Michael Herndon]

+1 for wiki checklist  ticket for for build scripts to bundle all this
stuff for you.

On Sun, Nov 20, 2011 at 1:51 AM, Prescott Nasser geobmx...@hotmail.comwrote:

 Damn It - knew i was missing something

 Sent from my Windows Phone
 
 From: Stefan Bodewig
 Sent: 11/19/2011 10:34 PM
 To: lucene-net-...@incubator.apache.org
 Subject: Re: [Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

 On 2011-11-18, Prescott Nasser wrote:

  Third time is the charm:

 I'm afraid it is not.

  http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/

 Sigs and hashes are good.  Source zip and tag match except for the
 build/lib/doc dirs that are only inside the tag and which I agree is a
 good thing for now.

 LICENSE, NOTICE, DISCLAIMER look good in src.

 There is no NOTICE and no DISCLAIMER in the binary zip.  Has it been
 this way before?  If so I'm sorry I didn't catch it.  This is a blocker
 for me and probably would be for the other IPMC members as well.

 RAT is reasonably happy with the source tree.

 I can't give a +1 because of the missing files in the binary zip.  If
 you just recreated the binary with the two files added (and obviously
 resigned it and recalculated the hashes) I'd be happy to change that.

 Cheers

Stefan

[Lucene.Net] [VOTE] Apache-Lucene.Net-2.9.4-incubating-RC3

[Prescott Nasser]

Third time is the charm:

 

http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC3/

 

I'll keep it open for 72 hours or so, then if all goes well, I'll make a vote 
to the general@incubator

 

Thanks everyone for their help getting to this point.

 

~Prescott

 

+1

Re: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation

[Christopher Currens]

I don't understand why we have the rendered html in the docs.  I don't mind
having the .chm rendered and put in the repo, but the entire HTML
documentation spans 8,000 files and over 100mb.  The CHM comes in at around
15mb.

I don't think it's necessary to have both in the repo, but if the consensus
is to keep them both, I think we should bundle the HTML docs in a zip,
instead of being added as loose files, at least in trunk.  I think it's
kinda silly the way it is now, and SVN does better at handling 1 large file
versus 8,000 smaller ones.

On Mon, Nov 7, 2011 at 6:53 AM, Michael Herndon mhern...@wickedsoftware.net
 wrote:

 @Stefan.

 I wouldn't worry about the taking the blame, you've done plenty to help out
 and there is no way to catch everything. We'll learn as we go.

 As svnpub is the only option and since we can't run the binary version that
 uses ASP.NET, we'll need to probably take your suggestion commit the
 smaller chunks of html then.

 I'll do it manually this time and see if I can't write a script that
 automates it in the future.

 @Chris, thanks for the fixes to the build scripts this weekend.

 - Michael


 On Mon, Nov 7, 2011 at 9:20 AM, Stefan Bodewig bode...@apache.org wrote:

  On 2011-11-07, Michael Herndon wrote:
 
   I can rebuild it, but the trick is replacing the version of it in svn
 so
   that it does not cause svnsync and cms to choke. Last time I just
 pushed
  it
   into branch/site/docs.  However, that is not publicly visible for the
   incubation website, so Prescott had to do an svn move.
 
  When I recommended to do the svn move I didn't realize we were talking
  about that many files.  I simply didn't check, sorry.
 
   I'm not quite sure how to go about it this time around. I would push it
  to
   jira, but it caps uploads at 10 mb.
 
  Then it still had to go to svn in some way.
 
  Personally I'm not a friend of generated documents in svn but I'm in a
  minority here.
 
  With svnpubsub being your only option I think the only thing you can do
  is split the commit into smaller chunks, committing 100 or 200 files at
  a time.  Maybe infra has better ideas than that, I don't.
 
  Stefan
 

RE: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation

[Prescott Nasser]

My intention is to link it to the website, so we have browsable documentation

 




 Date: Mon, 7 Nov 2011 19:26:23 -0800
 From: currens.ch...@gmail.com
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation

 I don't understand why we have the rendered html in the docs. I don't mind
 having the .chm rendered and put in the repo, but the entire HTML
 documentation spans 8,000 files and over 100mb. The CHM comes in at around
 15mb.

 I don't think it's necessary to have both in the repo, but if the consensus
 is to keep them both, I think we should bundle the HTML docs in a zip,
 instead of being added as loose files, at least in trunk. I think it's
 kinda silly the way it is now, and SVN does better at handling 1 large file
 versus 8,000 smaller ones.

 On Mon, Nov 7, 2011 at 6:53 AM, Michael Herndon mhern...@wickedsoftware.net
  wrote:

  @Stefan.
 
  I wouldn't worry about the taking the blame, you've done plenty to help out
  and there is no way to catch everything. We'll learn as we go.
 
  As svnpub is the only option and since we can't run the binary version that
  uses ASP.NET, we'll need to probably take your suggestion commit the
  smaller chunks of html then.
 
  I'll do it manually this time and see if I can't write a script that
  automates it in the future.
 
  @Chris, thanks for the fixes to the build scripts this weekend.
 
  - Michael
 
 
  On Mon, Nov 7, 2011 at 9:20 AM, Stefan Bodewig bode...@apache.org wrote:
 
   On 2011-11-07, Michael Herndon wrote:
  
I can rebuild it, but the trick is replacing the version of it in svn
  so
that it does not cause svnsync and cms to choke. Last time I just
  pushed
   it
into branch/site/docs. However, that is not publicly visible for the
incubation website, so Prescott had to do an svn move.
  
   When I recommended to do the svn move I didn't realize we were talking
   about that many files. I simply didn't check, sorry.
  
I'm not quite sure how to go about it this time around. I would push it
   to
jira, but it caps uploads at 10 mb.
  
   Then it still had to go to svn in some way.
  
   Personally I'm not a friend of generated documents in svn but I'm in a
   minority here.
  
   With svnpubsub being your only option I think the only thing you can do
   is split the commit into smaller chunks, committing 100 or 200 files at
   a time. Maybe infra has better ideas than that, I don't.
  
   Stefan
  

[Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation

[Christopher Currens]

A few days ago, after RC1 was put up for a vote to release, I started
working on [LUCENENET-438] by cleaning up the documentation.  The current
state of the documentation is pretty bad, there are many unconverted
remnants of javadoc comments (ie, @link, @see, etc..).  I wanted to do this
simply to get our documentation up to a more readable level.

I had expected this to take quite a long time, but with the magic of
regular expressions and find and replace, I'm nearly done with the
conversion, this all on the heels of the RC2 that was just put up to vote.
 I will probably wind up finishing the cleanup of the documentation
comments before Monday.  I would have said something earlier had I known it
wouldn't take me long and I likely wouldn't have made a vote on releasing
RC2.

So, if no one is opposed to it, we may consider to wait on RC2, regenerate
new documentation after I push the changes to SVN, and package it for
another RC (Sorry, Prescott!!).  It might be nice to have those
documentation issues fixed.  Like I said before, I hadn't really expected
to finish it so quickly, and hadn't even though it could be ready in time
for 2.9.4 release.


Thanks,
Christopher

RE: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation

[Prescott Nasser]

I dont mind

Sent from my Windows Phone

From: Christopher Currens
Sent: 11/4/2011 5:08 PM
To: lucene-net-dev@lucene.apache.org
Subject: [Lucene.Net] Lucene.Net-2.9.4-incubator-RC2 Documentation

A few days ago, after RC1 was put up for a vote to release, I started
working on [LUCENENET-438] by cleaning up the documentation.  The current
state of the documentation is pretty bad, there are many unconverted
remnants of javadoc comments (ie, @link, @see, etc..).  I wanted to do this
simply to get our documentation up to a more readable level.

I had expected this to take quite a long time, but with the magic of
regular expressions and find and replace, I'm nearly done with the
conversion, this all on the heels of the RC2 that was just put up to vote.
 I will probably wind up finishing the cleanup of the documentation
comments before Monday.  I would have said something earlier had I known it
wouldn't take me long and I likely wouldn't have made a vote on releasing
RC2.

So, if no one is opposed to it, we may consider to wait on RC2, regenerate
new documentation after I push the changes to SVN, and package it for
another RC (Sorry, Prescott!!).  It might be nice to have those
documentation issues fixed.  Like I said before, I hadn't really expected
to finish it so quickly, and hadn't even though it could be ready in time
for 2.9.4 release.


Thanks,
Christopher

Re: [Lucene.Net] [VOTE] Lucene.Net-2.9.4-incubator-RC2 Release

[Stefan Bodewig]

On 2011-11-02, Prescott Nasser wrote:

 http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC2/

As usual, no technical opinion at all, I leave that to others.

Sigs and hashes look good.  NOTICE and LICENSE are fine.

RAT is almost happy, we should add license headers to
src/contrib/DistributedSearch/LuceneMonitorSetup/LuceneMonitorSetup.vdproj
and test/contrib/SpellChecker/Contrib.SpellChecker.Test.nunit but these
are not blockers to me.  Two files is not the same as 120 files.

Source distribution and
http://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_9_4_RC2/
don't match exactly, the READMEs are different.  The one of the source
distribution says .NET 3.5, the one of the tag says 2.0.  No biggy but
you should adjust the tag IMHO.

Wearing my IPMC heat I don't see any reason to block the release, so +1
from me.

Stefan

Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Stefan Bodewig]

On 2011-10-31, Prescott Nasser wrote:

 Artifacts are located here:
 http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/

Is there a tag in svn that is supposed to correspond to them?  My guess
is http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/.
But then I find

diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs Apache-Lucene.Net-2.
9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
--- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs  2011-04-23 01:53:05.3476
64000 +0200
+++ Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
reLikeThis.cs   2011-10-30 19:35:42.0 +0100
@@ -769,7 +769,7 @@
 {
 for (int j = 0; j  text.Length; j++)
 {
-AddTermFrequencies(new System.IO.StreamReader(text[
j]), termFreqMap, fieldName);
+AddTermFrequencies(new System.IO.StringReader(text[
j]), termFreqMap, fieldName);
 }
 }
 }
@@ -820,7 +820,7 @@
 /// /param
 /// param name=fieldNameUsed by analyzer for any special per-field 
analysis
 /// /param
-private void  AddTermFrequencies(System.IO.StreamReader r, 
System.Collections.IDictionary termFreqMap, System.String fieldName)
+private void  AddTermFrequencies(System.IO.TextReader r, 
System.Collections.IDictionary termFreqMap, System.String fieldName)
 {
 TokenStream ts = analyzer.TokenStream(fieldName, r);
 Lucene.Net.Analysis.Token token;

so they don't match.

The src ZIP doesn't contain build.cmd nor the doc and lib folders.  Is
this intentional?

Signatures and checksums match.

The src ZIP contains .svn folders which I don't think they should.  No
biggie just something to fix for the next release or RC.  Same for some
.suo files and obj folders.

The binary distribution needs LICENSE.txt and NOTICE.txt that I can't
seem to find.  This forces a -1 from me.

The only other test I'd perform was running RAT which I'll do shortly
and post the results here.

Stefan

RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

bleh - forgot to update the branch.

 

And yay for windows hiding those svn files.. 

 

I'll give it a day or so and see what others might say then update it and call 
a new vote.

 

Thanks for taking the time to review

 

~P


 From: bode...@apache.org
 To: lucene-net-...@incubator.apache.org
 Date: Mon, 31 Oct 2011 07:00:08 +0100
 Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

 On 2011-10-31, Prescott Nasser wrote:

  Artifacts are located here:
  http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/

 Is there a tag in svn that is supposed to correspond to them? My guess
 is http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/.
 But then I find

 diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 
 Apache-Lucene.Net-2.
 9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
 --- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 2011-04-23 
 01:53:05.3476
 64000 +0200
 +++ 
 Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
 reLikeThis.cs 2011-10-30 19:35:42.0 +0100
 @@ -769,7 +769,7 @@
 {
 for (int j = 0; j  text.Length; j++)
 {
 - AddTermFrequencies(new System.IO.StreamReader(text[
 j]), termFreqMap, fieldName);
 + AddTermFrequencies(new System.IO.StringReader(text[
 j]), termFreqMap, fieldName);
 }
 }
 }
 @@ -820,7 +820,7 @@
 /// /param
 /// param name=fieldNameUsed by analyzer for any special per-field
 analysis
 /// /param
 - private void AddTermFrequencies(System.IO.StreamReader r, 
 System.Collections.IDictionary termFreqMap, System.String fieldName)
 + private void AddTermFrequencies(System.IO.TextReader r, 
 System.Collections.IDictionary termFreqMap, System.String fieldName)
 {
 TokenStream ts = analyzer.TokenStream(fieldName, r);
 Lucene.Net.Analysis.Token token;

 so they don't match.

 The src ZIP doesn't contain build.cmd nor the doc and lib folders. Is
 this intentional?

 Signatures and checksums match.

 The src ZIP contains .svn folders which I don't think they should. No
 biggie just something to fix for the next release or RC. Same for some
 .suo files and obj folders.

 The binary distribution needs LICENSE.txt and NOTICE.txt that I can't
 seem to find. This forces a -1 from me.

 The only other test I'd perform was running RAT which I'll do shortly
 and post the results here.

 Stefan  

Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Stefan Bodewig]

On 2011-10-31, Stefan Bodewig wrote:

 The only other test I'd perform was running RAT which I'll do shortly
 and post the results here.

The binary look good, but

http://people.apache.org/~bodewig/lucene.net/src.rat.txt

Way too many files without license headers.  I can and will provide a
patch to trunk fixing issues there (my svn trunk version of RAT is
better suited to do that than the latest release) but I recall this RC
was created from a branch so it may be of more help if I created the
patch for that one.

Stefan

RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

I have to re tag the trunk because of the additional bug fix I put in this 
evening. So feel free to update the trunk, I'll re tag it 2.9.4 RC2 once that's 
ready

 

~Prescott


 From: bode...@apache.org
 To: lucene-net-...@incubator.apache.org
 Date: Mon, 31 Oct 2011 07:10:46 +0100
 Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

 On 2011-10-31, Stefan Bodewig wrote:

  The only other test I'd perform was running RAT which I'll do shortly
  and post the results here.

 The binary look good, but

 http://people.apache.org/~bodewig/lucene.net/src.rat.txt

 Way too many files without license headers. I can and will provide a
 patch to trunk fixing issues there (my svn trunk version of RAT is
 better suited to do that than the latest release) but I recall this RC
 was created from a branch so it may be of more help if I created the
 patch for that one.

 Stefan  

RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

Michael - how do we stand with the sandcastle documentation generation?. I'm 
not familiar with using it, but we basically have no real documentation for 
this. It would be great to be able to generate documentation that we can then 
bundle with 2.9.4.


Stefan - doc folder was left out intentionally for this reason. Also the Lib 
folder, I left out, I thought it was additional dll's that weren't part of 
Lucene that others might need. I can put that back in. Not even sure what the 
build.cmd file is, but I'll investigate and get it in there.

 

 





 From: bode...@apache.org
 To: lucene-net-...@incubator.apache.org
 Date: Mon, 31 Oct 2011 07:00:08 +0100
 Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

 On 2011-10-31, Prescott Nasser wrote:

  Artifacts are located here:
  http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/

 Is there a tag in svn that is supposed to correspond to them? My guess
 is http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/.
 But then I find

 diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 
 Apache-Lucene.Net-2.
 9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
 --- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 2011-04-23 
 01:53:05.3476
 64000 +0200
 +++ 
 Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
 reLikeThis.cs 2011-10-30 19:35:42.0 +0100
 @@ -769,7 +769,7 @@
 {
 for (int j = 0; j  text.Length; j++)
 {
 - AddTermFrequencies(new System.IO.StreamReader(text[
 j]), termFreqMap, fieldName);
 + AddTermFrequencies(new System.IO.StringReader(text[
 j]), termFreqMap, fieldName);
 }
 }
 }
 @@ -820,7 +820,7 @@
 /// /param
 /// param name=fieldNameUsed by analyzer for any special per-field
 analysis
 /// /param
 - private void AddTermFrequencies(System.IO.StreamReader r, 
 System.Collections.IDictionary termFreqMap, System.String fieldName)
 + private void AddTermFrequencies(System.IO.TextReader r, 
 System.Collections.IDictionary termFreqMap, System.String fieldName)
 {
 TokenStream ts = analyzer.TokenStream(fieldName, r);
 Lucene.Net.Analysis.Token token;

 so they don't match.

 The src ZIP doesn't contain build.cmd nor the doc and lib folders. Is
 this intentional?

 Signatures and checksums match.

 The src ZIP contains .svn folders which I don't think they should. No
 biggie just something to fix for the next release or RC. Same for some
 .suo files and obj folders.

 The binary distribution needs LICENSE.txt and NOTICE.txt that I can't
 seem to find. This forces a -1 from me.

 The only other test I'd perform was running RAT which I'll do shortly
 and post the results here.

 Stefan  

Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Stefan Bodewig]

On 2011-10-31, Prescott Nasser wrote:

 Stefan - doc folder was left out intentionally for this reason.

OK.  I wonder whether it should be moved out of trunk.

 Also the Lib folder, I left out, I thought it was additional dll's
 that weren't part of Lucene that others might need. I can put that
 back in.

Please don't.  We'd need to review whether we can re-distribute all
those DLLs complying with ASF policies anyway.

Stefan

Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Michael Herndon]

@Prescott,

In name of getting this out the door and keeping momentum I'll put those
together and push that into svn sometime late tonight. **

Other things to do once released  official nuget package, some website
love. and start using the twitter: LuceneDotNet account.  I can help with
these as well.

@all,

If everyone involved for this release could put some time aside after this
release to co-write a checklist/steps to put on the wiki for the release
process in one place, that would be awesome.


**reasoning.
We've yet to get the SHFB installed on builds and thus I need to write up
some instructions for the installer as it been causing some pain for CI.
Once that hurdle is crossed, I'd like to work with a few people
contributors or committers to make sure others can create docs.  But for
now, there is no point in obstructing the release with that. We've made an
hard line effort at all things outstanding in the last few months and we
should keep with the momentum of getting this out the door.


- Michael





On Mon, Oct 31, 2011 at 2:14 AM, Prescott Nasser geobmx...@hotmail.comwrote:






 Michael - how do we stand with the sandcastle documentation generation?.
 I'm not familiar with using it, but we basically have no real documentation
 for this. It would be great to be able to generate documentation that we
 can then bundle with 2.9.4.


 Stefan - doc folder was left out intentionally for this reason. Also the
 Lib folder, I left out, I thought it was additional dll's that weren't part
 of Lucene that others might need. I can put that back in. Not even sure
 what the build.cmd file is, but I'll investigate and get it in there.








 
  From: bode...@apache.org
  To: lucene-net-...@incubator.apache.org
  Date: Mon, 31 Oct 2011 07:00:08 +0100
  Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
 
  On 2011-10-31, Prescott Nasser wrote:
 
   Artifacts are located here:
   http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
 
  Is there a tag in svn that is supposed to correspond to them? My guess
  is http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/.
  But then I find
 
  diff -ur svn/src/contrib/Similarity/Similar/MoreLikeThis.cs
 Apache-Lucene.Net-2.
  9.4-incubating-RC1.src/src/contrib/Similarity/Similar/MoreLikeThis.cs
  --- svn/src/contrib/Similarity/Similar/MoreLikeThis.cs 2011-04-23
 01:53:05.3476
  64000 +0200
  +++
 Apache-Lucene.Net-2.9.4-incubating-RC1.src/src/contrib/Similarity/Similar/Mo
  reLikeThis.cs 2011-10-30 19:35:42.0 +0100
  @@ -769,7 +769,7 @@
  {
  for (int j = 0; j  text.Length; j++)
  {
  - AddTermFrequencies(new System.IO.StreamReader(text[
  j]), termFreqMap, fieldName);
  + AddTermFrequencies(new System.IO.StringReader(text[
  j]), termFreqMap, fieldName);
  }
  }
  }
  @@ -820,7 +820,7 @@
  /// /param
  /// param name=fieldNameUsed by analyzer for any special per-field
  analysis
  /// /param
  - private void AddTermFrequencies(System.IO.StreamReader r,
 System.Collections.IDictionary termFreqMap, System.String fieldName)
  + private void AddTermFrequencies(System.IO.TextReader r,
 System.Collections.IDictionary termFreqMap, System.String fieldName)
  {
  TokenStream ts = analyzer.TokenStream(fieldName, r);
  Lucene.Net.Analysis.Token token;
 
  so they don't match.
 
  The src ZIP doesn't contain build.cmd nor the doc and lib folders. Is
  this intentional?
 
  Signatures and checksums match.
 
  The src ZIP contains .svn folders which I don't think they should. No
  biggie just something to fix for the next release or RC. Same for some
  .suo files and obj folders.
 
  The binary distribution needs LICENSE.txt and NOTICE.txt that I can't
  seem to find. This forces a -1 from me.
 
  The only other test I'd perform was running RAT which I'll do shortly
  and post the results here.
 
  Stefan

Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Michael Herndon]

 wrote:
 
  Artifacts are located here:
 http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/
 
 
  If the vote passes here, I will move the artifacts to staging and call a
 vote on the general incubator mailing list
 
 
 
  Please verify the release and cast your vote.  The vote will be open for
 72 hours.
 
  [ ] +1
  [ ]  0
  [ ] -1
 
 
 
 
 
  ~Prescott

Re: [Lucene.Net] 2.9.4 RC1

[Itamar Syn-Hershko]

Any chance you guys fix and merge this
https://issues.apache.org/jira/browse/LUCENENET-450 before releasing?

On Sun, Oct 30, 2011 at 11:12 PM, Prescott Nasser geobmx...@hotmail.comwrote:




 Alright- this took me way too long, I'm sorry for that.



 Could you guys please take a look at:
 http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/hopefully 
 I've done this right, once you guys think it looks good, I'd like
 to call a vote to release this



 ~Prescott

RE: [Lucene.Net] 2.9.4 RC1

[Prescott Nasser]

Done - i've uploaded the new files to the same place. I actually found an issue 
with the bin.zip file, so it was good that I merged that bug fix in.

 

If you guys don't mind taking a look, I'd like to submit it to the incubator 
mailing list for a vote tomorrow if we have no issues with these

 

~Prescott


 Date: Mon, 31 Oct 2011 01:14:52 +0200
 From: ita...@code972.com
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4 RC1

 Any chance you guys fix and merge this
 https://issues.apache.org/jira/browse/LUCENENET-450 before releasing?

 On Sun, Oct 30, 2011 at 11:12 PM, Prescott Nasser 
 geobmx...@hotmail.comwrote:

 
 
 
  Alright- this took me way too long, I'm sorry for that.
 
 
 
  Could you guys please take a look at:
  http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/hopefully 
  I've done this right, once you guys think it looks good, I'd like
  to call a vote to release this
 
 
 
  ~Prescott

Re: [Lucene.Net] 2.9.4 RC1

[Stefan Bodewig]

Hi Prescott,

thank you for pushing things forward.

On 2011-10-31, Prescott Nasser wrote:

 Done - i've uploaded the new files to the same place. I actually found
 an issue with the bin.zip file, so it was good that I merged that bug
 fix in.

I'm pretty sure you know that, but if you decide to do something like
this after you've started the vote, please cancel the vote, bump the RC
number and start a new vote.

 If you guys don't mind taking a look, I'd like to submit it to the
 incubator mailing list for a vote tomorrow if we have no issues with
 these

Start a VOTE thread on this list and if it passes go to the general
list.  If all mentors vote on this list the VOTE on the general list is
more informational than anything else.

I'll look into the ZIPs myself in a few hours so you'll know how I'm
going to vote 8-)

Stefan

RE: [Lucene.Net] 2.9.4 RC1

[Prescott Nasser]

  Done - i've uploaded the new files to the same place. I actually found
  an issue with the bin.zip file, so it was good that I merged that bug
  fix in.

 I'm pretty sure you know that, but if you decide to do something like
 this after you've started the vote, please cancel the vote, bump the RC
 number and start a new vote.


Check

 


  If you guys don't mind taking a look, I'd like to submit it to the
  incubator mailing list for a vote tomorrow if we have no issues with
  these

 Start a VOTE thread on this list and if it passes go to the general
 list. If all mentors vote on this list the VOTE on the general list is
 more informational than anything else.


 

Done!


 I'll look into the ZIPs myself in a few hours so you'll know how I'm
 going to vote 8-)

 Stefan  

[Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

Artifacts are located here: 
http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/


If the vote passes here, I will move the artifacts to staging and call a vote 
on the general incubator mailing list

 

Please verify the release and cast your vote.  The vote will be open for 72 
hours.

[ ] +1
[ ]  0
[ ] -1

 

 

~Prescott 

RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating

[Prescott Nasser]

+1



 From: geobmx...@hotmail.com
 To: lucene-net-dev@lucene.apache.org
 Date: Sun, 30 Oct 2011 22:08:32 -0700
 Subject: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating


 Artifacts are located here: 
 http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/


 If the vote passes here, I will move the artifacts to staging and call a vote 
 on the general incubator mailing list



 Please verify the release and cast your vote. The vote will be open for 72 
 hours.

 [ ] +1
 [ ] 0
 [ ] -1





 ~Prescott   

Re: [Lucene.Net] 2.9.4

[Stefan Bodewig]

On 2011-10-03, Prescott Nasser wrote:

 I think we're ready, i just dont know the procedures to call a vote.

Don't know the exact details for Lucene.Net but the general approach is
likely always the same.

* Make sure your PGP key is inside the KEYS file people will use to
  check the artifacts

* tag the tree that is going to become the release
  (svn cp trunk tags/2.9.4RC1 - or something like that)

* build the release artifacts, hash and sign them

* upload the release artifacts to you personal homepage
  on people.apache.org

* call for a vote on this list listing the svn tag (including the
  revision number would be good) and the location where to find the
  artifacts.

* if the vote fails, adapt and start with a new tag (incrementing the
  number after the RC)

* if the vote passes, copy the tag to 2.9.4 without any RC, copy the
  artifacts to your incubator dist area, wait for a few hours to allow
  the mirrors to catch up, update download page and publish it, announce
  wherever you feel it is appropriate

Stefan

RE: [Lucene.Net] 2.9.4

[casper...@caspershouse.com]

Prescott,


You can do one of two things:


- Remove the volatile keyword, but keep the lock statement around the 
access to the field

- Remove the lock, and add the volatile keyword to the field


This will allow you to assign to the _infoStream variable (read/write) and 
be sure to have the most up-to-date value in the variable, as well as 
guarantee atomic reads/writes to that variable.


Your example is incorrect.  The volatile on p only guarantees that 
reads/writes will be current if p is changed.  In other words, if you 
assign a new person instance to p, you can do so without using a lock 
statement and guarantee that the reads/writes from p will be atomic.


However, any calls you make to p are not protected, not because of 
volatile.  Volatile will *never* be able to protect calls, it only protects 
variables.


Lock, on the other hand, can protect calls, assuming that you cover all the 
calls with the same lock.  You can also group other operations and make 
sure that synchronization occurs.


Note that a lock *only* guarantees atomicity/mutual exclusion; when applied 
to multiple statements, there's no guarantee that you won't corrupt 
something.  If an exception is thrown inside of a lock statement (the 
second line in three lines of code in the lock block, for example) then the 
previous values don't roll back or anything.


Because atomicity with a variable assignment is mutually exclusive around 
*one* operation, there's no chance of corruption.


Let me know if you want further clarification.


Additionally, if you have a specific patch/issue in JIRA you want me to 
look at, let me know, I'll let you know if the solution is right from a 
thread-safety point of view.


- Nick



From: Prescott Nasser geobmx...@hotmail.com

Sent: Friday, September 23, 2011 1:17 AM

To: lucene-net-dev@lucene.apache.org

Subject: RE: [Lucene.Net] 2.9.4


I see, so you're essentially saying, I can simply remove the volatile 
keyword in this case, and it's exactly the same becuase I am only using it 
for read and writes?


So the case I'd need to be more careful of is if an manipulation method is 
called on the object itself - suppose:


public person {


_name = Me   


public changeName(string n)


{


_name = n;


}


}


If one were to write 


public volatile person p = new person();


p.changeName(You);


the call to the method would in this case need a lock (which volatile 
gives) to gaurentee that changeName occurs before other items read or 
overwrite variable p?


but a straight read or write won't matter:


p = new person();


p = new person():


x = p;


p = new person();


Here, I wouldn't need the volatile keyword becuase those are merely reads 
and wrights?




 CC: lucene-net-dev@lucene.apache.org

 From: casper...@caspershouse.com

 Date: Thu, 22 Sep 2011 23:58:42 -0400

 To: lucene-net-dev@lucene.apache.org

 Subject: Re: [Lucene.Net] 2.9.4



 Prescott,



 You really don't need to do that; reads and writes of reference fields 
are guaranteed to be atomic as per section 5.5 of the C# Language 
Specufication (Atomicity of variable references)



 If you were doing other operations beyond the read and write that you 
wanted to be atomic, then the lock statement is appropriate, but in this 
case it's not.



 The volatile keyword in this case (assuming no lock) would absolutely be 
needed to guarantee that the variable has the most up-to-date value at the 
time of access; using lock does this for you and makes volatile 
unnecessary.



 - Nick







 On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com 
wrote:



 

  Before I go replacing all the volatile fields I wanted to run this past 
the list:

 

 

 

  private System.IO.StreamWriter infoStream;

 

 

  into

 

 

 

  private object o = new object();

  private System.IO.StreamWriter _infoStream;

  private System.IO.StreamWriter infoStream

  {

  get

  {

  lock (o)

  {

  return _infoStream;

  }

  }

  set

  {

  lock (o)

  {

  _infoStream = value;

  }

  }

  }

 

 

 

 

 

  Sorry, I don't normally deal with locks..

 

 

 

  Thanks for any guidance

 

 

 

  ~P

 

 

  @Prescott,

  Can the volatile fields be wrapped in a lock statement and code that 
access

  those fields with replaced with call to a property /method that wraps 
access

  to that field?

 

 

 

 

  On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com 
wrote:

 

  I thought it was:

 

  2.9.2 and before are 2.0 compatible

  2.9.4 and before are 3.5 compatible

  After 2.9.4 are 4.0 compatible

 

  Thanks,

  Troy

 

  On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon

  mhern...@wickedsoftware.net wrote:

  if thats the case, then well need conditional statements for 
including

  ThreadLocalT

 

  On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser 
geobmx...@hotmail.com

  wrote:

 

  I thought this was after 2.9.4

 

  Sent

RE: [Lucene.Net] 2.9.4

[casper...@caspershouse.com]

NP



From: Prescott Nasser geobmx...@hotmail.com

Sent: Friday, September 23, 2011 9:31 AM

To: lucene-net-dev@lucene.apache.org, casper...@caspershouse.com

Subject: RE: [Lucene.Net] 2.9.4


That helps thanks. No Jira although I will put one in.


Sent from my Windows Phone


-Original Message-

From: casper...@caspershouse.com

Sent: Friday, September 23, 2011 6:05 AM

To: lucene-net-dev@lucene.apache.org

Subject: RE: [Lucene.Net] 2.9.4


Prescott,


You can do one of two things:


- Remove the volatile keyword, but keep the lock statement around the

access to the field


- Remove the lock, and add the volatile keyword to the field


This will allow you to assign to the _infoStream variable (read/write) and

be sure to have the most up-to-date value in the variable, as well as

guarantee atomic reads/writes to that variable.


Your example is incorrect.  The volatile on p only guarantees that

reads/writes will be current if p is changed.  In other words, if you

assign a new person instance to p, you can do so without using a lock

statement and guarantee that the reads/writes from p will be atomic.


However, any calls you make to p are not protected, not because of

volatile.  Volatile will *never* be able to protect calls, it only 
protects

variables.


Lock, on the other hand, can protect calls, assuming that you cover all 
the

calls with the same lock.  You can also group other operations and make

sure that synchronization occurs.


Note that a lock *only* guarantees atomicity/mutual exclusion; when 
applied

to multiple statements, there's no guarantee that you won't corrupt

something.  If an exception is thrown inside of a lock statement (the

second line in three lines of code in the lock block, for example) then 
the

previous values don't roll back or anything.


Because atomicity with a variable assignment is mutually exclusive around

*one* operation, there's no chance of corruption.


Let me know if you want further clarification.


Additionally, if you have a specific patch/issue in JIRA you want me to

look at, let me know, I'll let you know if the solution is right from a

thread-safety point of view.


- Nick





From: Prescott Nasser geobmx...@hotmail.com


Sent: Friday, September 23, 2011 1:17 AM


To: lucene-net-dev@lucene.apache.org


Subject: RE: [Lucene.Net] 2.9.4


I see, so you're essentially saying, I can simply remove the volatile

keyword in this case, and it's exactly the same becuase I am only using it

for read and writes?


So the case I'd need to be more careful of is if an manipulation method is

called on the object itself - suppose:


public person {


_name = Me


public changeName(string n)


{


_name = n;


}


}


If one were to write


public volatile person p = new person();


p.changeName(You);


the call to the method would in this case need a lock (which volatile

gives) to gaurentee that changeName occurs before other items read or

overwrite variable p?


but a straight read or write won't matter:


p = new person();


p = new person():


x = p;


p = new person();


Here, I wouldn't need the volatile keyword becuase those are merely reads

and wrights?





 CC: lucene-net-dev@lucene.apache.org


 From: casper...@caspershouse.com


 Date: Thu, 22 Sep 2011 23:58:42 -0400


 To: lucene-net-dev@lucene.apache.org


 Subject: Re: [Lucene.Net] 2.9.4





 Prescott,





 You really don't need to do that; reads and writes of reference fields

are guaranteed to be atomic as per section 5.5 of the C# Language

Specufication (Atomicity of variable references)





 If you were doing other operations beyond the read and write that you

wanted to be atomic, then the lock statement is appropriate, but in this

case it's not.





 The volatile keyword in this case (assuming no lock) would absolutely be

needed to guarantee that the variable has the most up-to-date value at the

time of access; using lock does this for you and makes volatile

unnecessary.





 - Nick











 On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com

wrote:





 


  Before I go replacing all the volatile fields I wanted to run this 
past

the list:


 


 


 


  private System.IO.StreamWriter infoStream;


 


 


  into


 


 


 


  private object o = new object();


  private System.IO.StreamWriter _infoStream;


  private System.IO.StreamWriter infoStream


  {


  get


  {


  lock (o)


  {


  return _infoStream;


  }


  }


  set


  {


  lock (o)


  {


  _infoStream = value;


  }


  }


  }


 


 


 


 


 


  Sorry, I don't normally deal with locks..


 


 


 


  Thanks for any guidance


 


 


 


  ~P


 


 


  @Prescott,


  Can the volatile fields be wrapped in a lock statement and code that

access


  those fields with replaced with call to a property /method that wraps

access


  to that field

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

So I now have the scripts exporting the html site.  Does the current
cms/site some how link to ~/site/docs ?

Or if we publish the documents online they would need to into two
directories ~/site/docs/version for posterity  ~/site/trunk/content/
lucene.net/docs/version  for everyone to view them online?

On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com wrote:

 At one time I had a SVN server set up at work that had a post-commit
 hook set up that would generate a static HTML site from the XML doc
 files using Sandcastle. So.. It can be done. That was about 3-4 years
 ago and I don't work at that company any longer, so I don't have
 access to the details of how that was done.

 Regarding SVN locations...

 Autogenerated XML doc files should go in the ~/trunk/doc/component
 folders. The Sandcastle generated static HTML should go under
 ~/site/docs/version folders.

 I'll see if I can't dig up some info on how to generate static HTML
 with Sandcastle.

 Thanks,
 Troy


 On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
 mhern...@wickedsoftware.net wrote:
 We have a folder /trunk/docs, shouldn't this be the place for that?
 
  We should have a live site for the documentation that people can browse,
  similar to the parent project's site.
  http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
  documentation more accessible.
 
  The rub is that Sandcastle  SHFB generates html files with guid names,
 xml
   bin files that map to the html files, and aspx pages which acts as the
  glue. The aspx pages parses the xml/bin files which creates the document
  site.  Thus we're now required to use a server that knows how to serve up
  aspx pages.
 
  If any one knows a way to generate just vanilla html using Sandcastle 
  SHFB, I could just create a folder per version and push the docs to
  incubator site. But so far I haven't found an option for this.
 
  Keeping the generated help docs inside of source would still require for
  users to setup a local website just to view the documentation and it adds
  extra noise in the project.
 
  In the release we can provide a zipped file of the site and a generated
 .chm
  or even help2/3 files.
 
  On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:
 
 
  
   We should probably fix the ClsCompliance warnings if they have not
  already
   been fixed
 
 
 
 
 
  We will have some issues with this - some are marked volatile - which
  basically have to be a non-CLS compliant type (as far as my research is
  finding) Anyone have thoughts? I went through and replaced sbyte -
 Int16,
  and uint - Int64, but I'm having an issue with this, and I don't think
  removing the volatile keyword is the right solution.
 
 
 
   find a place to put the generated documentation.
 
 
  We have a folder /trunk/docs, shouldn't this be the place for that?
 
 
 
  
   I remember someone mentioning he/she was unable to access a class from
   VB.NET. The class had public fields  properties with the same names
 but
   different casing. The fields should be private.
  
 
 
 
 
 
 
   The link in the readme is a dead link:
   http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
   sandcastle  SHFB require a server that allows aspx files to be
 executed.
   We should either remove the link from the readme or find the docs a
 new
   home and update the link.
 
 
  We should generate new documentation and update the link
 
 
 
  
   I'll see if I can setup automating Lucene.Net http://lucene.net
 nuget
   package creation for trunk in the next day or so.
  
   - Michael
  
   On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser 
 geobmx...@hotmail.com
  wrote:
  
Hey all seems like we are set with 2.9.4? Feedback has been positive
  and
its been quiet. Do we feel ready to vote for a new release?
   
-Prescott
   
Sent from my Windows Phone
 
 

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Before I go replacing all the volatile fields I wanted to run this past the 
list:

 

private System.IO.StreamWriter infoStream;


into

 

private object o = new object();
private System.IO.StreamWriter _infoStream;
private System.IO.StreamWriter infoStream
{
 get
 {
lock (o)
{
return _infoStream;
}
 }
set
{
lock (o)
{
_infoStream = value;
}
}
 }  

 

 

Sorry, I don't normally deal with locks..

 

Thanks for any guidance

 

~P


 @Prescott,
 Can the volatile fields be wrapped in a lock statement and code that access
 those fields with replaced with call to a property /method that wraps access
 to that field?




 On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:

  I thought it was:
 
  2.9.2 and before are 2.0 compatible
  2.9.4 and before are 3.5 compatible
  After 2.9.4 are 4.0 compatible
 
  Thanks,
  Troy
 
  On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
  mhern...@wickedsoftware.net wrote:
   if thats the case, then well need conditional statements for including
   ThreadLocalT
  
   On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
  wrote:
  
   I thought this was after 2.9.4
  
   Sent from my Windows Phone
  
   -Original Message-
   From: Michael Herndon
   Sent: Wednesday, September 21, 2011 8:30 AM
   To: lucene-net-dev@lucene.apache.org
   Cc: lucene-net-...@incubator.apache.org
   Subject: Re: [Lucene.Net] 2.9.4
  
   @Robert,
  
   I believe the overwhelming consensus on the mailing list vote was to
  move
   to
   .NET 4.0 and drop support for previous versions.
  
   I'll take care of build scripts issue while they being refactored into
   smaller chunks this week.
  
   @Troy, Agreed.
  
   On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
  
On 20.09.2011 23:48, Prescott Nasser wrote:
   
Hey all seems like we are set with 2.9.4? Feedback has been positive
  and
its been quiet. Do we feel ready to vote for a new release?
   
   
I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:
   
Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and build/scripts/contrib.targets.
   
The following patches should fix the issue:
   
https://github.com/robert-j/**lucene.net/commit/**
c5218bca56c19b3407648224781eec**7316994a39
  
  https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
   
   
https://github.com/robert-j/**lucene.net/commit/**
50bad187655d59968d51d472b57c2a**40e201d663
  
  https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
   
   
   
Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:
   
https://github.com/apache/**lucene.net/commit/**
23ea6f52362fc7dbce48fd012cea12**9a7350c73c
  
  https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
   
   
Did we agree about abandoning .NET = 3.5?
   
Robert
   
   
  
  

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

The line before had volatile in it..

 

private volatile System.IO.StreamWriter infoStream;


 From: geobmx...@hotmail.com
 To: lucene-net-dev@lucene.apache.org
 Date: Thu, 22 Sep 2011 20:14:41 -0700
 Subject: RE: [Lucene.Net] 2.9.4


 Before I go replacing all the volatile fields I wanted to run this past the 
 list:



 private System.IO.StreamWriter infoStream;


 into



 private object o = new object();
 private System.IO.StreamWriter _infoStream;
 private System.IO.StreamWriter infoStream
 {
 get
 {
 lock (o)
 {
 return _infoStream;
 }
 }
 set
 {
 lock (o)
 {
 _infoStream = value;
 }
 }
 }





 Sorry, I don't normally deal with locks..



 Thanks for any guidance



 ~P

 
  @Prescott,
  Can the volatile fields be wrapped in a lock statement and code that access
  those fields with replaced with call to a property /method that wraps access
  to that field?
 
 
 
 
  On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
 
   I thought it was:
  
   2.9.2 and before are 2.0 compatible
   2.9.4 and before are 3.5 compatible
   After 2.9.4 are 4.0 compatible
  
   Thanks,
   Troy
  
   On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
   mhern...@wickedsoftware.net wrote:
if thats the case, then well need conditional statements for including
ThreadLocalT
   
On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
   wrote:
   
I thought this was after 2.9.4
   
Sent from my Windows Phone
   
-Original Message-
From: Michael Herndon
Sent: Wednesday, September 21, 2011 8:30 AM
To: lucene-net-dev@lucene.apache.org
Cc: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4
   
@Robert,
   
I believe the overwhelming consensus on the mailing list vote was to
   move
to
.NET 4.0 and drop support for previous versions.
   
I'll take care of build scripts issue while they being refactored into
smaller chunks this week.
   
@Troy, Agreed.
   
On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
   
 On 20.09.2011 23:48, Prescott Nasser wrote:

 Hey all seems like we are set with 2.9.4? Feedback has been positive
   and
 its been quiet. Do we feel ready to vote for a new release?


 I don't know if the build infrastructure is part of the
 release. If yes, then there is an open issue:

 Contrib doesn't build right now because there
 are some assembly name mismatches between certain *.csproj
 files and build/scripts/contrib.targets.

 The following patches should fix the issue:

 https://github.com/robert-j/**lucene.net/commit/**
 c5218bca56c19b3407648224781eec**7316994a39
   
   https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39


 https://github.com/robert-j/**lucene.net/commit/**
 50bad187655d59968d51d472b57c2a**40e201d663
   
   https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663



 Also, the fix for [LUCENENET-358] is basically making
 Lucene.Net.dll a .NET 4.0-only assembly:

 https://github.com/apache/**lucene.net/commit/**
 23ea6f52362fc7dbce48fd012cea12**9a7350c73c
   
   https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c


 Did we agree about abandoning .NET = 3.5?

 Robert


   
   
   

Re: [Lucene.Net] 2.9.4

[Nicholas Paldino [.NET/C MVP#]]

Prescott,

You really don't need to do that; reads and writes of reference fields are 
guaranteed to be atomic as per section 5.5 of the C# Language Specufication 
(Atomicity of variable references)

If you were doing other operations beyond the read and write that you wanted to 
be atomic, then the lock statement is appropriate, but in this case it's not.

The volatile keyword in this case (assuming no lock) would absolutely be needed 
to guarantee that the variable has the most up-to-date value at the time of 
access; using lock does this for you and makes volatile unnecessary.

- Nick 



On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com wrote:

 
 Before I go replacing all the volatile fields I wanted to run this past the 
 list:
 
 
 
 private System.IO.StreamWriter infoStream;
 
 
 into
 
 
 
 private object o = new object();
 private System.IO.StreamWriter _infoStream;
 private System.IO.StreamWriter infoStream
 {
 get
 {
lock (o)
{
return _infoStream;
}
 }
set
{
lock (o)
{
_infoStream = value;
}
}
 }  
 
 
 
 
 
 Sorry, I don't normally deal with locks..
 
 
 
 Thanks for any guidance
 
 
 
 ~P
 
 
 @Prescott,
 Can the volatile fields be wrapped in a lock statement and code that access
 those fields with replaced with call to a property /method that wraps access
 to that field?
 
 
 
 
 On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
 
 I thought it was:
 
 2.9.2 and before are 2.0 compatible
 2.9.4 and before are 3.5 compatible
 After 2.9.4 are 4.0 compatible
 
 Thanks,
 Troy
 
 On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
 mhern...@wickedsoftware.net wrote:
 if thats the case, then well need conditional statements for including
 ThreadLocalT
 
 On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:
 
 I thought this was after 2.9.4
 
 Sent from my Windows Phone
 
 -Original Message-
 From: Michael Herndon
 Sent: Wednesday, September 21, 2011 8:30 AM
 To: lucene-net-dev@lucene.apache.org
 Cc: lucene-net-...@incubator.apache.org
 Subject: Re: [Lucene.Net] 2.9.4
 
 @Robert,
 
 I believe the overwhelming consensus on the mailing list vote was to
 move
 to
 .NET 4.0 and drop support for previous versions.
 
 I'll take care of build scripts issue while they being refactored into
 smaller chunks this week.
 
 @Troy, Agreed.
 
 On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
 
 On 20.09.2011 23:48, Prescott Nasser wrote:
 
 Hey all seems like we are set with 2.9.4? Feedback has been positive
 and
 its been quiet. Do we feel ready to vote for a new release?
 
 
 I don't know if the build infrastructure is part of the
 release. If yes, then there is an open issue:
 
 Contrib doesn't build right now because there
 are some assembly name mismatches between certain *.csproj
 files and build/scripts/contrib.targets.
 
 The following patches should fix the issue:
 
 https://github.com/robert-j/**lucene.net/commit/**
 c5218bca56c19b3407648224781eec**7316994a39
 
 https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
 
 
 https://github.com/robert-j/**lucene.net/commit/**
 50bad187655d59968d51d472b57c2a**40e201d663
 
 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
 
 
 
 Also, the fix for [LUCENENET-358] is basically making
 Lucene.Net.dll a .NET 4.0-only assembly:
 
 https://github.com/apache/**lucene.net/commit/**
 23ea6f52362fc7dbce48fd012cea12**9a7350c73c
 
 https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
 
 
 Did we agree about abandoning .NET = 3.5?
 
 Robert
 
 
 
 
 

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

I see, so you're essentially saying, I can simply remove the volatile keyword 
in this case, and it's exactly the same becuase I am only using it for read and 
writes?

 

So the case I'd need to be more careful of is if an manipulation method is 
called on the object itself - suppose:

 

public person {

_name = Me   

 

public changeName(string n)

{

   _name = n;

}

 

}

 

If one were to write 

 

public volatile person p = new person();

p.changeName(You);

 

the call to the method would in this case need a lock (which volatile gives) to 
gaurentee that changeName occurs before other items read or overwrite variable 
p?

 

but a straight read or write won't matter:

 

p = new person();

p = new person():

x = p;

p = new person();

 

Here, I wouldn't need the volatile keyword becuase those are merely reads and 
wrights?



 CC: lucene-net-dev@lucene.apache.org
 From: casper...@caspershouse.com
 Date: Thu, 22 Sep 2011 23:58:42 -0400
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 Prescott,

 You really don't need to do that; reads and writes of reference fields are 
 guaranteed to be atomic as per section 5.5 of the C# Language Specufication 
 (Atomicity of variable references)

 If you were doing other operations beyond the read and write that you wanted 
 to be atomic, then the lock statement is appropriate, but in this case it's 
 not.

 The volatile keyword in this case (assuming no lock) would absolutely be 
 needed to guarantee that the variable has the most up-to-date value at the 
 time of access; using lock does this for you and makes volatile unnecessary.

 - Nick



 On Sep 22, 2011, at 11:14 PM, Prescott Nasser geobmx...@hotmail.com wrote:

 
  Before I go replacing all the volatile fields I wanted to run this past the 
  list:
 
 
 
  private System.IO.StreamWriter infoStream;
 
 
  into
 
 
 
  private object o = new object();
  private System.IO.StreamWriter _infoStream;
  private System.IO.StreamWriter infoStream
  {
  get
  {
  lock (o)
  {
  return _infoStream;
  }
  }
  set
  {
  lock (o)
  {
  _infoStream = value;
  }
  }
  }
 
 
 
 
 
  Sorry, I don't normally deal with locks..
 
 
 
  Thanks for any guidance
 
 
 
  ~P
 
 
  @Prescott,
  Can the volatile fields be wrapped in a lock statement and code that access
  those fields with replaced with call to a property /method that wraps 
  access
  to that field?
 
 
 
 
  On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:
 
  I thought it was:
 
  2.9.2 and before are 2.0 compatible
  2.9.4 and before are 3.5 compatible
  After 2.9.4 are 4.0 compatible
 
  Thanks,
  Troy
 
  On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
  mhern...@wickedsoftware.net wrote:
  if thats the case, then well need conditional statements for including
  ThreadLocalT
 
  On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
  wrote:
 
  I thought this was after 2.9.4
 
  Sent from my Windows Phone
 
  -Original Message-
  From: Michael Herndon
  Sent: Wednesday, September 21, 2011 8:30 AM
  To: lucene-net-dev@lucene.apache.org
  Cc: lucene-net-...@incubator.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
  @Robert,
 
  I believe the overwhelming consensus on the mailing list vote was to
  move
  to
  .NET 4.0 and drop support for previous versions.
 
  I'll take care of build scripts issue while they being refactored into
  smaller chunks this week.
 
  @Troy, Agreed.
 
  On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
 
  On 20.09.2011 23:48, Prescott Nasser wrote:
 
  Hey all seems like we are set with 2.9.4? Feedback has been positive
  and
  its been quiet. Do we feel ready to vote for a new release?
 
 
  I don't know if the build infrastructure is part of the
  release. If yes, then there is an open issue:
 
  Contrib doesn't build right now because there
  are some assembly name mismatches between certain *.csproj
  files and build/scripts/contrib.targets.
 
  The following patches should fix the issue:
 
  https://github.com/robert-j/**lucene.net/commit/**
  c5218bca56c19b3407648224781eec**7316994a39
 
  https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
 
 
  https://github.com/robert-j/**lucene.net/commit/**
  50bad187655d59968d51d472b57c2a**40e201d663
 
  https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
 
 
 
  Also, the fix for [LUCENENET-358] is basically making
  Lucene.Net.dll a .NET 4.0-only assembly:
 
  https://github.com/apache/**lucene.net/commit/**
  23ea6f52362fc7dbce48fd012cea12**9a7350c73c
 
  https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
 
 
  Did we agree about abandoning .NET = 3.5?
 
  Robert
 
 
 
 
 

 

Re: [Lucene.Net] 2.9.4

[Troy Howard]

I thought it was:

2.9.2 and before are 2.0 compatible
2.9.4 and before are 3.5 compatible
After 2.9.4 are 4.0 compatible

Thanks,
Troy

On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
mhern...@wickedsoftware.net wrote:
 if thats the case, then well need conditional statements for including
 ThreadLocalT

 On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser 
 geobmx...@hotmail.comwrote:

 I thought this was after 2.9.4

 Sent from my Windows Phone

 -Original Message-
 From: Michael Herndon
 Sent: Wednesday, September 21, 2011 8:30 AM
 To: lucene-net-dev@lucene.apache.org
 Cc: lucene-net-...@incubator.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 @Robert,

 I believe the overwhelming consensus on the mailing list vote was to move
 to
 .NET 4.0 and drop support for previous versions.

 I'll take care of build scripts issue while they being refactored into
 smaller chunks this week.

 @Troy, Agreed.

 On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:

  On 20.09.2011 23:48, Prescott Nasser wrote:
 
  Hey all seems like we are set with 2.9.4? Feedback has been positive and
  its been quiet. Do we feel ready to vote for a new release?
 
 
  I don't know if the build infrastructure is part of the
  release. If yes, then there is an open issue:
 
  Contrib doesn't build right now because there
  are some assembly name mismatches between certain *.csproj
  files and  build/scripts/contrib.targets.
 
  The following patches should fix the issue:
 
  https://github.com/robert-j/**lucene.net/commit/**
  c5218bca56c19b3407648224781eec**7316994a39
 https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
 
 
  https://github.com/robert-j/**lucene.net/commit/**
  50bad187655d59968d51d472b57c2a**40e201d663
 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
 
 
 
  Also, the fix for [LUCENENET-358] is basically making
  Lucene.Net.dll a .NET 4.0-only assembly:
 
  https://github.com/apache/**lucene.net/commit/**
  23ea6f52362fc7dbce48fd012cea12**9a7350c73c
 https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
 
 
  Did we agree about abandoning .NET = 3.5?
 
  Robert
 
 

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

@all,

I updated the build scripts to increase it's granularity.
https://cwiki.apache.org/LUCENENET/build-system-scripts.html

Similarity was include, though are there any tests for this project ?

Some of the contrib tests are failing, I saw a few in Contrib.Highlighter
just glancing at the output .

I recieved some feedback Eric Woodruff. It looks like SHFB  Sandcastle
generate a plain file html, its been staring me in the face this whole time.
 I'll need to build in some targets that extract whats needed to push to
site branch. Then I'll start working on nuget.

@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps access
to that field?




On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:

 I thought it was:

 2.9.2 and before are 2.0 compatible
 2.9.4 and before are 3.5 compatible
 After 2.9.4 are 4.0 compatible

 Thanks,
 Troy

 On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
 mhern...@wickedsoftware.net wrote:
  if thats the case, then well need conditional statements for including
  ThreadLocalT
 
  On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:
 
  I thought this was after 2.9.4
 
  Sent from my Windows Phone
 
  -Original Message-
  From: Michael Herndon
  Sent: Wednesday, September 21, 2011 8:30 AM
  To: lucene-net-dev@lucene.apache.org
  Cc: lucene-net-...@incubator.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
  @Robert,
 
  I believe the overwhelming consensus on the mailing list vote was to
 move
  to
  .NET 4.0 and drop support for previous versions.
 
  I'll take care of build scripts issue while they being refactored into
  smaller chunks this week.
 
  @Troy, Agreed.
 
  On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
 
   On 20.09.2011 23:48, Prescott Nasser wrote:
  
   Hey all seems like we are set with 2.9.4? Feedback has been positive
 and
   its been quiet. Do we feel ready to vote for a new release?
  
  
   I don't know if the build infrastructure is part of the
   release. If yes, then there is an open issue:
  
   Contrib doesn't build right now because there
   are some assembly name mismatches between certain *.csproj
   files and  build/scripts/contrib.targets.
  
   The following patches should fix the issue:
  
   https://github.com/robert-j/**lucene.net/commit/**
   c5218bca56c19b3407648224781eec**7316994a39
 
 https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec7316994a39
  
  
   https://github.com/robert-j/**lucene.net/commit/**
   50bad187655d59968d51d472b57c2a**40e201d663
 
 https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
  
  
  
   Also, the fix for [LUCENENET-358] is basically making
   Lucene.Net.dll a .NET 4.0-only assembly:
  
   https://github.com/apache/**lucene.net/commit/**
   23ea6f52362fc7dbce48fd012cea12**9a7350c73c
 
 https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a7350c73c
  
  
   Did we agree about abandoning .NET = 3.5?
  
   Robert
  
  
 
 

RE: [Lucene.Net] 2.9.4

[Digy]

 Similarity was include, though are there any tests for this project ?
Similarity is obsolete (Queries.Net replaces it  has test cases). It has
already been removed in 2.9.4g

DIGY

-Original Message-
From: Michael Herndon [mailto:mhern...@wickedsoftware.net] 
Sent: Wednesday, September 21, 2011 10:40 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4

@all,

I updated the build scripts to increase it's granularity.
https://cwiki.apache.org/LUCENENET/build-system-scripts.html

Similarity was include, though are there any tests for this project ?

Some of the contrib tests are failing, I saw a few in Contrib.Highlighter
just glancing at the output .

I recieved some feedback Eric Woodruff. It looks like SHFB  Sandcastle
generate a plain file html, its been staring me in the face this whole time.
 I'll need to build in some targets that extract whats needed to push to
site branch. Then I'll start working on nuget.

@Prescott,
Can the volatile fields be wrapped in a lock statement and code that access
those fields with replaced with call to a property /method that wraps access
to that field?




On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard thowar...@gmail.com wrote:

 I thought it was:

 2.9.2 and before are 2.0 compatible
 2.9.4 and before are 3.5 compatible
 After 2.9.4 are 4.0 compatible

 Thanks,
 Troy

 On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
 mhern...@wickedsoftware.net wrote:
  if thats the case, then well need conditional statements for including
  ThreadLocalT
 
  On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:
 
  I thought this was after 2.9.4
 
  Sent from my Windows Phone
 
  -Original Message-
  From: Michael Herndon
  Sent: Wednesday, September 21, 2011 8:30 AM
  To: lucene-net-dev@lucene.apache.org
  Cc: lucene-net-...@incubator.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
  @Robert,
 
  I believe the overwhelming consensus on the mailing list vote was to
 move
  to
  .NET 4.0 and drop support for previous versions.
 
  I'll take care of build scripts issue while they being refactored into
  smaller chunks this week.
 
  @Troy, Agreed.
 
  On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan robe...@gmx.net wrote:
 
   On 20.09.2011 23:48, Prescott Nasser wrote:
  
   Hey all seems like we are set with 2.9.4? Feedback has been positive
 and
   its been quiet. Do we feel ready to vote for a new release?
  
  
   I don't know if the build infrastructure is part of the
   release. If yes, then there is an open issue:
  
   Contrib doesn't build right now because there
   are some assembly name mismatches between certain *.csproj
   files and  build/scripts/contrib.targets.
  
   The following patches should fix the issue:
  
   https://github.com/robert-j/**lucene.net/commit/**
   c5218bca56c19b3407648224781eec**7316994a39
 

https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
7316994a39
  
  
   https://github.com/robert-j/**lucene.net/commit/**
   50bad187655d59968d51d472b57c2a**40e201d663
 

https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
40e201d663
  
  
  
   Also, the fix for [LUCENENET-358] is basically making
   Lucene.Net.dll a .NET 4.0-only assembly:
  
   https://github.com/apache/**lucene.net/commit/**
   23ea6f52362fc7dbce48fd012cea12**9a7350c73c
 

https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
7350c73c
  
  
   Did we agree about abandoning .NET = 3.5?
  
   Robert
  
  
 
 


-

Checked by AVG - www.avg.com
Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11

RE: [Lucene.Net] 2.9.4

[Digy]

@Robert 

 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a
.NET 4.0-only assembly:

There is a commented part at the end of the CloseableThreadLocal which may
seem familiar to you :)
No harm in uncommenting it and no conditional compilation is needed. 
It also pass all test cases.

DIGY



-Original Message-
From: Robert Jordan [mailto:robe...@gmx.net] 
Sent: Wednesday, September 21, 2011 3:09 PM
To: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4

On 20.09.2011 23:48, Prescott Nasser wrote:
 Hey all seems like we are set with 2.9.4? Feedback has been positive and
its been quiet. Do we feel ready to vote for a new release?

I don't know if the build infrastructure is part of the
release. If yes, then there is an open issue:

Contrib doesn't build right now because there
are some assembly name mismatches between certain *.csproj
files and  build/scripts/contrib.targets.

The following patches should fix the issue:

https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
7316994a39

https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
40e201d663


Also, the fix for [LUCENENET-358] is basically making
Lucene.Net.dll a .NET 4.0-only assembly:

https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
7350c73c

Did we agree about abandoning .NET = 3.5?

Robert

-

Checked by AVG - www.avg.com
Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11

RE: [Lucene.Net] 2.9.4

[Digy]

You are right in race condition  NullReferenceException. 
but 
static SupportClass.WeakHashTable slots = new
SupportClass.WeakHashTable();
wouldn't work since it is intented to be created in all threads not once.

Would you patch it or leave it to me?

Thanks,
DIGY

-Original Message-
From: Robert Jordan [mailto:robe...@gmx.net] 
Sent: Thursday, September 22, 2011 1:16 AM
To: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4

Hi Digy,

On 21.09.2011 23:38, Digy wrote:
 @Robert

 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a
 .NET 4.0-only assembly:

 There is a commented part at the end of the CloseableThreadLocal which may
 seem familiar to you :)

Indeed :) I've missed this comment.

 No harm in uncommenting it and no conditional compilation is needed.
 It also pass all test cases.

BTW, there is an issue with this commented-out code. If Value
is not accessed at least once, Dispose() will fail with a
NullReferenceException. There is also a little chance for
a race condition.

I'd rather get rid of Init() for this code:

static SupportClass.WeakHashTable slots = new SupportClass.WeakHashTable();

Robert


 DIGY



 -Original Message-
 From: Robert Jordan [mailto:robe...@gmx.net]
 Sent: Wednesday, September 21, 2011 3:09 PM
 To: lucene-net-...@incubator.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 On 20.09.2011 23:48, Prescott Nasser wrote:
 Hey all seems like we are set with 2.9.4? Feedback has been positive and
 its been quiet. Do we feel ready to vote for a new release?

 I don't know if the build infrastructure is part of the
 release. If yes, then there is an open issue:

 Contrib doesn't build right now because there
 are some assembly name mismatches between certain *.csproj
 files and  build/scripts/contrib.targets.

 The following patches should fix the issue:


https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
 7316994a39


https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
 40e201d663


 Also, the fix for [LUCENENET-358] is basically making
 Lucene.Net.dll a .NET 4.0-only assembly:


https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
 7350c73c

 Did we agree about abandoning .NET= 3.5?

 Robert

 -

 Checked by AVG - www.avg.com
 Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11




-

Checked by AVG - www.avg.com
Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11

RE: [Lucene.Net] 2.9.4

[Digy]

I reconsidered it and there is no race condition.  A new slot will be
created for each thread.
But NullReferenceException bug is still there.

DIGY

-Original Message-
From: Robert Jordan [mailto:robe...@gmx.net] 
Sent: Thursday, September 22, 2011 1:16 AM
To: lucene-net-...@incubator.apache.org
Subject: Re: [Lucene.Net] 2.9.4

Hi Digy,

On 21.09.2011 23:38, Digy wrote:
 @Robert

 Also, the fix for [LUCENENET-358] is basically making Lucene.Net.dll a
 .NET 4.0-only assembly:

 There is a commented part at the end of the CloseableThreadLocal which may
 seem familiar to you :)

Indeed :) I've missed this comment.

 No harm in uncommenting it and no conditional compilation is needed.
 It also pass all test cases.

BTW, there is an issue with this commented-out code. If Value
is not accessed at least once, Dispose() will fail with a
NullReferenceException. There is also a little chance for
a race condition.

I'd rather get rid of Init() for this code:

static SupportClass.WeakHashTable slots = new SupportClass.WeakHashTable();

Robert


 DIGY



 -Original Message-
 From: Robert Jordan [mailto:robe...@gmx.net]
 Sent: Wednesday, September 21, 2011 3:09 PM
 To: lucene-net-...@incubator.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 On 20.09.2011 23:48, Prescott Nasser wrote:
 Hey all seems like we are set with 2.9.4? Feedback has been positive and
 its been quiet. Do we feel ready to vote for a new release?

 I don't know if the build infrastructure is part of the
 release. If yes, then there is an open issue:

 Contrib doesn't build right now because there
 are some assembly name mismatches between certain *.csproj
 files and  build/scripts/contrib.targets.

 The following patches should fix the issue:


https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
 7316994a39


https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
 40e201d663


 Also, the fix for [LUCENENET-358] is basically making
 Lucene.Net.dll a .NET 4.0-only assembly:


https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
 7350c73c

 Did we agree about abandoning .NET= 3.5?

 Robert

 -

 Checked by AVG - www.avg.com
 Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11




-

Checked by AVG - www.avg.com
Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 09/21/11

Re: [Lucene.Net] 2.9.4

[Itamar Syn-Hershko]

Big OK from our end

Sorry to be nagging on this again, but it would be very nice if you could
incorporate https://issues.apache.org/jira/browse/LUCENENET-431 in 2.9.4 as
well. It is one of those bugfixes that really fix a lot more than they can
possible break, so I hope this will justify a small divergence from JL.

On Wed, Sep 21, 2011 at 1:29 AM, Michael Herndon 
mhern...@wickedsoftware.net wrote:

 We should probably  fix the ClsCompliance warnings if they have not already
 been fixed  find a place to put the generated documentation.

 I remember someone mentioning he/she was unable to access a class from
 VB.NET. The class had public fields  properties with the same names but
 different casing.  The fields should be private.

 The link in the readme is a dead link:
 http://lucene.apache.org/lucene.net/docs/2.4.0/   The docs generated by
 sandcastle  SHFB require a server that allows aspx files to be executed.
  We should either remove the link from the readme or find the docs a new
 home and update the link.

 I'll see if I can setup automating Lucene.Net http://lucene.net nuget
 package creation for trunk in the next day or so.

 - Michael

 On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:

  Hey all seems like we are set with 2.9.4? Feedback has been positive and
  its been quiet. Do we feel ready to vote for a new release?
 
  -Prescott
 
  Sent from my Windows Phone

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

 We should probably fix the ClsCompliance warnings if they have not already
 been fixed 

 

 

We will have some issues with this - some are marked volatile - which basically 
have to be a non-CLS compliant type (as far as my research is finding) Anyone 
have thoughts? I went through and replaced sbyte - Int16, and uint - Int64, 
but I'm having an issue with this, and I don't think removing the volatile 
keyword is the right solution.

 

 find a place to put the generated documentation.


We have a folder /trunk/docs, shouldn't this be the place for that?

 


 I remember someone mentioning he/she was unable to access a class from
 VB.NET. The class had public fields  properties with the same names but
 different casing. The fields should be private.



 

 

 The link in the readme is a dead link:
 http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
 sandcastle  SHFB require a server that allows aspx files to be executed.
 We should either remove the link from the readme or find the docs a new
 home and update the link.


We should generate new documentation and update the link

 


 I'll see if I can setup automating Lucene.Net http://lucene.net nuget
 package creation for trunk in the next day or so.

 - Michael

 On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.comwrote:

  Hey all seems like we are set with 2.9.4? Feedback has been positive and
  its been quiet. Do we feel ready to vote for a new release?
 
  -Prescott
 
  Sent from my Windows Phone

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

We have a folder /trunk/docs, shouldn't this be the place for that?

We should have a live site for the documentation that people can browse,
similar to the parent project's site.
http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
documentation more accessible.

The rub is that Sandcastle  SHFB generates html files with guid names, xml
 bin files that map to the html files, and aspx pages which acts as the
glue. The aspx pages parses the xml/bin files which creates the document
site.  Thus we're now required to use a server that knows how to serve up
aspx pages.

If any one knows a way to generate just vanilla html using Sandcastle 
SHFB, I could just create a folder per version and push the docs to
incubator site. But so far I haven't found an option for this.

Keeping the generated help docs inside of source would still require for
users to setup a local website just to view the documentation and it adds
extra noise in the project.

In the release we can provide a zipped file of the site and a generated .chm
or even help2/3 files.

On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.comwrote:


 
  We should probably fix the ClsCompliance warnings if they have not
 already
  been fixed





 We will have some issues with this - some are marked volatile - which
 basically have to be a non-CLS compliant type (as far as my research is
 finding) Anyone have thoughts? I went through and replaced sbyte - Int16,
 and uint - Int64, but I'm having an issue with this, and I don't think
 removing the volatile keyword is the right solution.



  find a place to put the generated documentation.


 We have a folder /trunk/docs, shouldn't this be the place for that?



 
  I remember someone mentioning he/she was unable to access a class from
  VB.NET. The class had public fields  properties with the same names but
  different casing. The fields should be private.
 






  The link in the readme is a dead link:
  http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
  sandcastle  SHFB require a server that allows aspx files to be executed.
  We should either remove the link from the readme or find the docs a new
  home and update the link.


 We should generate new documentation and update the link



 
  I'll see if I can setup automating Lucene.Net http://lucene.net nuget
  package creation for trunk in the next day or so.
 
  - Michael
 
  On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:
 
   Hey all seems like we are set with 2.9.4? Feedback has been positive
 and
   its been quiet. Do we feel ready to vote for a new release?
  
   -Prescott
  
   Sent from my Windows Phone

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

Could we store sandcastle docs as a single zip/chm?



On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com wrote:

 At one time I had a SVN server set up at work that had a post-commit
 hook set up that would generate a static HTML site from the XML doc
 files using Sandcastle. So.. It can be done. That was about 3-4 years
 ago and I don't work at that company any longer, so I don't have
 access to the details of how that was done.

 Regarding SVN locations...

 Autogenerated XML doc files should go in the ~/trunk/doc/component
 folders. The Sandcastle generated static HTML should go under
 ~/site/docs/version folders.

 I'll see if I can't dig up some info on how to generate static HTML
 with Sandcastle.

 Thanks,
 Troy


 On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
 mhern...@wickedsoftware.net wrote:
 We have a folder /trunk/docs, shouldn't this be the place for that?
 
  We should have a live site for the documentation that people can browse,
  similar to the parent project's site.
  http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
  documentation more accessible.
 
  The rub is that Sandcastle  SHFB generates html files with guid names,
 xml
   bin files that map to the html files, and aspx pages which acts as the
  glue. The aspx pages parses the xml/bin files which creates the document
  site.  Thus we're now required to use a server that knows how to serve up
  aspx pages.
 
  If any one knows a way to generate just vanilla html using Sandcastle 
  SHFB, I could just create a folder per version and push the docs to
  incubator site. But so far I haven't found an option for this.
 
  Keeping the generated help docs inside of source would still require for
  users to setup a local website just to view the documentation and it adds
  extra noise in the project.
 
  In the release we can provide a zipped file of the site and a generated
 .chm
  or even help2/3 files.
 
  On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:
 
 
  
   We should probably fix the ClsCompliance warnings if they have not
  already
   been fixed
 
 
 
 
 
  We will have some issues with this - some are marked volatile - which
  basically have to be a non-CLS compliant type (as far as my research is
  finding) Anyone have thoughts? I went through and replaced sbyte -
 Int16,
  and uint - Int64, but I'm having an issue with this, and I don't think
  removing the volatile keyword is the right solution.
 
 
 
   find a place to put the generated documentation.
 
 
  We have a folder /trunk/docs, shouldn't this be the place for that?
 
 
 
  
   I remember someone mentioning he/she was unable to access a class from
   VB.NET. The class had public fields  properties with the same names
 but
   different casing. The fields should be private.
  
 
 
 
 
 
 
   The link in the readme is a dead link:
   http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
   sandcastle  SHFB require a server that allows aspx files to be
 executed.
   We should either remove the link from the readme or find the docs a
 new
   home and update the link.
 
 
  We should generate new documentation and update the link
 
 
 
  
   I'll see if I can setup automating Lucene.Net http://lucene.net
 nuget
   package creation for trunk in the next day or so.
  
   - Michael
  
   On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser 
 geobmx...@hotmail.com
  wrote:
  
Hey all seems like we are set with 2.9.4? Feedback has been positive
  and
its been quiet. Do we feel ready to vote for a new release?
   
-Prescott
   
Sent from my Windows Phone
 
 

Re: [Lucene.Net] 2.9.4

[Troy Howard]

Why would we want to do that?

Under the /site/docs directory, they need to be served up as loose HTML...

IMO the XML files shouldn't be checked into SVN because they are
auto-generated. The same goes for Sandcastle files.. However, in the
release packages, I think we should include the XML files as well as a
fully functional version of the Sandcastle docs that can be viewed
locally. I personally thing CHMs are terrible user experience, and I'd
much rather have a static HTML site I can browse locally, if we're
going to bother including a copy of the documentation in the package,
vs just hosting it online and calling that good (this is what most
projects these days do). Good thing about hosting online -- searchable
via google.

Thanks,
Troy


On Tue, Sep 20, 2011 at 9:48 PM, Michael Herndon
mhern...@wickedsoftware.net wrote:
 Could we store sandcastle docs as a single zip/chm?



 On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com wrote:

 At one time I had a SVN server set up at work that had a post-commit
 hook set up that would generate a static HTML site from the XML doc
 files using Sandcastle. So.. It can be done. That was about 3-4 years
 ago and I don't work at that company any longer, so I don't have
 access to the details of how that was done.

 Regarding SVN locations...

 Autogenerated XML doc files should go in the ~/trunk/doc/component
 folders. The Sandcastle generated static HTML should go under
 ~/site/docs/version folders.

 I'll see if I can't dig up some info on how to generate static HTML
 with Sandcastle.

 Thanks,
 Troy


 On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
 mhern...@wickedsoftware.net wrote:
 We have a folder /trunk/docs, shouldn't this be the place for that?
 
  We should have a live site for the documentation that people can browse,
  similar to the parent project's site.
  http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
  documentation more accessible.
 
  The rub is that Sandcastle  SHFB generates html files with guid names,
 xml
   bin files that map to the html files, and aspx pages which acts as the
  glue. The aspx pages parses the xml/bin files which creates the document
  site.  Thus we're now required to use a server that knows how to serve up
  aspx pages.
 
  If any one knows a way to generate just vanilla html using Sandcastle 
  SHFB, I could just create a folder per version and push the docs to
  incubator site. But so far I haven't found an option for this.
 
  Keeping the generated help docs inside of source would still require for
  users to setup a local website just to view the documentation and it adds
  extra noise in the project.
 
  In the release we can provide a zipped file of the site and a generated
 .chm
  or even help2/3 files.
 
  On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:
 
 
  
   We should probably fix the ClsCompliance warnings if they have not
  already
   been fixed
 
 
 
 
 
  We will have some issues with this - some are marked volatile - which
  basically have to be a non-CLS compliant type (as far as my research is
  finding) Anyone have thoughts? I went through and replaced sbyte -
 Int16,
  and uint - Int64, but I'm having an issue with this, and I don't think
  removing the volatile keyword is the right solution.
 
 
 
   find a place to put the generated documentation.
 
 
  We have a folder /trunk/docs, shouldn't this be the place for that?
 
 
 
  
   I remember someone mentioning he/she was unable to access a class from
   VB.NET. The class had public fields  properties with the same names
 but
   different casing. The fields should be private.
  
 
 
 
 
 
 
   The link in the readme is a dead link:
   http://lucene.apache.org/lucene.net/docs/2.4.0/ The docs generated by
   sandcastle  SHFB require a server that allows aspx files to be
 executed.
   We should either remove the link from the readme or find the docs a
 new
   home and update the link.
 
 
  We should generate new documentation and update the link
 
 
 
  
   I'll see if I can setup automating Lucene.Net http://lucene.net
 nuget
   package creation for trunk in the next day or so.
  
   - Michael
  
   On Tue, Sep 20, 2011 at 5:48 PM, Prescott Nasser 
 geobmx...@hotmail.com
  wrote:
  
Hey all seems like we are set with 2.9.4? Feedback has been positive
  and
its been quiet. Do we feel ready to vote for a new release?
   
-Prescott
   
Sent from my Windows Phone
 
 

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

I'm with you on checking in the static files into ~/site/doc/version

that would be pretty easy to automate from jenkins  msbuild if we can get
the docs into static html.

 I currently just push all assemblies, help files, xml docs into ~/trunk/bin
on the user's local once the scripts finish building, running tests, and
reports. Nothing gets commited into svn from this at the moment.  The site
is generated, but not pushed anywhere.

I was waiting to see how aspx thing plays out  getting CI up with nuget
before setting up a build release build task that automates everything
including pushing the docs, finalized content, etc.

So my real question is, do we need to store static docs that are generate in
~/trunk/docs/?

If so, could we store those in a single file format and just provide a setup
script that takes care of extracting the latest for the user versus putting
all those files into trunk.

Technically someone could build an post process hook that builds up a static
html index  from xml  bin files, but I'm hoping it does not come to that.


 - Michael







On Wed, Sep 21, 2011 at 12:56 AM, Troy Howard thowar...@gmail.com wrote:

 Why would we want to do that?

 Under the /site/docs directory, they need to be served up as loose HTML...

 IMO the XML files shouldn't be checked into SVN because they are
 auto-generated. The same goes for Sandcastle files.. However, in the
 release packages, I think we should include the XML files as well as a
 fully functional version of the Sandcastle docs that can be viewed
 locally. I personally thing CHMs are terrible user experience, and I'd
 much rather have a static HTML site I can browse locally, if we're
 going to bother including a copy of the documentation in the package,
 vs just hosting it online and calling that good (this is what most
 projects these days do). Good thing about hosting online -- searchable
 via google.

 Thanks,
 Troy


 On Tue, Sep 20, 2011 at 9:48 PM, Michael Herndon
 mhern...@wickedsoftware.net wrote:
  Could we store sandcastle docs as a single zip/chm?
 
 
 
  On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com
 wrote:
 
  At one time I had a SVN server set up at work that had a post-commit
  hook set up that would generate a static HTML site from the XML doc
  files using Sandcastle. So.. It can be done. That was about 3-4 years
  ago and I don't work at that company any longer, so I don't have
  access to the details of how that was done.
 
  Regarding SVN locations...
 
  Autogenerated XML doc files should go in the ~/trunk/doc/component
  folders. The Sandcastle generated static HTML should go under
  ~/site/docs/version folders.
 
  I'll see if I can't dig up some info on how to generate static HTML
  with Sandcastle.
 
  Thanks,
  Troy
 
 
  On Tue, Sep 20, 2011 at 9:15 PM, Michael Herndon
  mhern...@wickedsoftware.net wrote:
  We have a folder /trunk/docs, shouldn't this be the place for that?
  
   We should have a live site for the documentation that people can
 browse,
   similar to the parent project's site.
   http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it
 the
   documentation more accessible.
  
   The rub is that Sandcastle  SHFB generates html files with guid
 names,
  xml
bin files that map to the html files, and aspx pages which acts as
 the
   glue. The aspx pages parses the xml/bin files which creates the
 document
   site.  Thus we're now required to use a server that knows how to serve
 up
   aspx pages.
  
   If any one knows a way to generate just vanilla html using Sandcastle
 
   SHFB, I could just create a folder per version and push the docs to
   incubator site. But so far I haven't found an option for this.
  
   Keeping the generated help docs inside of source would still require
 for
   users to setup a local website just to view the documentation and it
 adds
   extra noise in the project.
  
   In the release we can provide a zipped file of the site and a
 generated
  .chm
   or even help2/3 files.
  
   On Tue, Sep 20, 2011 at 11:38 PM, Prescott Nasser 
 geobmx...@hotmail.com
  wrote:
  
  
   
We should probably fix the ClsCompliance warnings if they have not
   already
been fixed
  
  
  
  
  
   We will have some issues with this - some are marked volatile - which
   basically have to be a non-CLS compliant type (as far as my research
 is
   finding) Anyone have thoughts? I went through and replaced sbyte -
  Int16,
   and uint - Int64, but I'm having an issue with this, and I don't
 think
   removing the volatile keyword is the right solution.
  
  
  
find a place to put the generated documentation.
  
  
   We have a folder /trunk/docs, shouldn't this be the place for that?
  
  
  
   
I remember someone mentioning he/she was unable to access a class
 from
VB.NET. The class had public fields  properties with the same
 names
  but
different casing. The fields should be private.
   
  
  
  
  
  
  
The link in the readme is a 

Re: [Lucene.Net] 2.9.4

[Itamar Syn-Hershko]

Hello again,

We are done with testing on our end. As far as we can tell, Lucene 2.9.4 is
good to go.

Now all that is left is to hope Digy will decide to have the Spatial.Net fix
in too so we can get the whole deal from nuget :)

On Sun, Sep 11, 2011 at 8:22 PM, Prescott Nasser geobmx...@hotmail.comwrote:


 Thanks Itamar!

 
  Date: Sat, 10 Sep 2011 20:22:59 +0300
  From: ita...@code972.com
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
  We have been running some extensive tests 30hrs now against the 2.9.4
  branch, and did not detect any leaks. We will have it running a few more
  days, if you wish to wait for more conclusive findings.
 
  On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser geobmx...@hotmail.com
 wrote:
 
   2.9.4 would make it in I assume because that will be our next official
   release.
  
  
   Sent from my Windows Phone
  
   -Original Message-
   From: Michael Herndon
   Sent: Wednesday, September 07, 2011 5:12 AM
   To: lucene-net-dev@lucene.apache.org
   Subject: Re: [Lucene.Net] 2.9.4
  
What version is going to make it to nuget? 2.9.4 or 2.9.4g?
   ooo totally forgot about nuget. we definitely need to get that setup.
  
  
   On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote:
  
Since it includes some level of divergence from java I committed it
 to
   only
2.9.4g branch.
   
https://issues.apache.org/jira/browse/LUCENE-1930
https://issues.apache.org/jira/browse/LUCENENET-431
   
DIGY
   
On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko 
 ita...@code972.com
wrote:
   
 Ok, core compiles, and all tests pass. We are now running long
 tests to
 measure memory usage among other things.

 There is one show stopper tho. There was a patch sent by Matt
 Warren
   for
 Spatial.Net, that doesn't seem to be in. See
 http://groups.google.com/group/ravendb/msg/7517f095810c48f3

 Any chance you can get it in to 2.9.4?

 On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko 
 ita...@code972.com
 wrote:

  Ok, great, we will run RavenDB on top of 2.9.4 in the next few
 days
   and
  will let you know how it went.
 
 
  On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon 
  mhern...@wickedsoftware.net wrote:
 
  I can't tell if the apache git mirror is updated via scheduler
 or
   from
  commit hooks, but its generally stays close to being on par with
   svn.
  I'll
  check next time I push something to svn.
 
  But both of those items have made it to the mirror.
 
  - michael
 
 
  On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com
 wrote:
 
   I don't know how often github mirror is updated.
   These are the original locations
   2.9.4
   https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
   2.9.4g
  
  
 

   
  
 https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
   9_4g/
  
   Both versions include ThreadLocal fix + Signing.
  
   Thanks,
   DIGY
  
  
  
   -Original Message-
   From: itamar.synhers...@gmail.com [mailto:
itamar.synhers...@gmail.com
 ]
  On
   Behalf Of Itamar Syn-Hershko
   Sent: Tuesday, September 06, 2011 2:34 AM
   To: lucene-net-dev@lucene.apache.org
   Subject: Re: [Lucene.Net] 2.9.4
  
   Not a problem, we will test RavenDB on a separate branch, also
 for
   potential
   memory leaks
  
   Digy, can you make sure the github mirror contains an updated
   2.9.4
 tag
  I
   can pull from, which includes the latest ThreadLocal fix + the
 strongly
   signed patch applied to it?
  
   2011/9/6 Digy digyd...@gmail.com
  
To avoid misunderstanding...
   
Community==all Lucene.Net users
   
DIGY
   
-Original Message-
From: Digy [mailto:digyd...@gmail.com]
Sent: Monday, September 05, 2011 11:46 PM
To: 'lucene-net-dev@lucene.apache.org'
Subject: RE: [Lucene.Net] 2.9.4
   
Not bad idea, but I would prefer community's feedback
 instead of
  testing
against all projects using Lucene.Net
DIGY
   
-Original Message-
From: Matt Warren [mailto:mattd...@gmail.com]
Sent: Monday, September 05, 2011 11:09 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4
   
If you want to test it against a large project you could
 take a
look
  at
   how
RavenDB uses it?
   
At the moment it's using 2.9.2 (
   
   
  
  
 

   
  
 https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
)
but if you were to recompile it against 2.9.4 and check that
 all
 it's

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Thanks Itamar!


 Date: Sat, 10 Sep 2011 20:22:59 +0300
 From: ita...@code972.com
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 We have been running some extensive tests 30hrs now against the 2.9.4
 branch, and did not detect any leaks. We will have it running a few more
 days, if you wish to wait for more conclusive findings.

 On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser geobmx...@hotmail.comwrote:

  2.9.4 would make it in I assume because that will be our next official
  release.
 
 
  Sent from my Windows Phone
 
  -Original Message-
  From: Michael Herndon
  Sent: Wednesday, September 07, 2011 5:12 AM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
   What version is going to make it to nuget? 2.9.4 or 2.9.4g?
  ooo totally forgot about nuget. we definitely need to get that setup.
 
 
  On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote:
 
   Since it includes some level of divergence from java I committed it to
  only
   2.9.4g branch.
  
   https://issues.apache.org/jira/browse/LUCENE-1930
   https://issues.apache.org/jira/browse/LUCENENET-431
  
   DIGY
  
   On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com
   wrote:
  
Ok, core compiles, and all tests pass. We are now running long tests to
measure memory usage among other things.
   
There is one show stopper tho. There was a patch sent by Matt Warren
  for
Spatial.Net, that doesn't seem to be in. See
http://groups.google.com/group/ravendb/msg/7517f095810c48f3
   
Any chance you can get it in to 2.9.4?
   
On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com
wrote:
   
 Ok, great, we will run RavenDB on top of 2.9.4 in the next few days
  and
 will let you know how it went.


 On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon 
 mhern...@wickedsoftware.net wrote:

 I can't tell if the apache git mirror is updated via scheduler or
  from
 commit hooks, but its generally stays close to being on par with
  svn.
 I'll
 check next time I push something to svn.

 But both of those items have made it to the mirror.

 - michael


 On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote:

  I don't know how often github mirror is updated.
  These are the original locations
  2.9.4
  https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
  2.9.4g
 
 

   
  
  https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
  9_4g/
 
  Both versions include ThreadLocal fix + Signing.
 
  Thanks,
  DIGY
 
 
 
  -Original Message-
  From: itamar.synhers...@gmail.com [mailto:
   itamar.synhers...@gmail.com
]
 On
  Behalf Of Itamar Syn-Hershko
  Sent: Tuesday, September 06, 2011 2:34 AM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
  Not a problem, we will test RavenDB on a separate branch, also for
  potential
  memory leaks
 
  Digy, can you make sure the github mirror contains an updated
  2.9.4
tag
 I
  can pull from, which includes the latest ThreadLocal fix + the
strongly
  signed patch applied to it?
 
  2011/9/6 Digy digyd...@gmail.com
 
   To avoid misunderstanding...
  
   Community==all Lucene.Net users
  
   DIGY
  
   -Original Message-
   From: Digy [mailto:digyd...@gmail.com]
   Sent: Monday, September 05, 2011 11:46 PM
   To: 'lucene-net-dev@lucene.apache.org'
   Subject: RE: [Lucene.Net] 2.9.4
  
   Not bad idea, but I would prefer community's feedback instead of
 testing
   against all projects using Lucene.Net
   DIGY
  
   -Original Message-
   From: Matt Warren [mailto:mattd...@gmail.com]
   Sent: Monday, September 05, 2011 11:09 PM
   To: lucene-net-dev@lucene.apache.org
   Subject: Re: [Lucene.Net] 2.9.4
  
   If you want to test it against a large project you could take a
   look
 at
  how
   RavenDB uses it?
  
   At the moment it's using 2.9.2 (
  
  
 
 

   
  
  https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
   )
   but if you were to recompile it against 2.9.4 and check that all
it's
   unit-tests still run that would give you quite a large test
  case.
  
   On 5 September 2011 19:22, Prescott Nasser 
  geobmx...@hotmail.com
   
  wrote:
  
   
Hey All,
   
How do people feel about the 2.9.4 code base? I've been using
  it
for
sometime, for my use cases it's be excellent. Do we feel we
  are
 ready
  to
package this up and make it an official release? Or do we have
some
  tasks
left

Re: [Lucene.Net] 2.9.4

[Itamar Syn-Hershko]

We have been running some extensive tests 30hrs now against the 2.9.4
branch, and did not detect any leaks. We will have it running a few more
days, if you wish to wait for more conclusive findings.

On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser geobmx...@hotmail.comwrote:

 2.9.4 would make it in I assume because that will be our next official
 release.


 Sent from my Windows Phone

 -Original Message-
 From: Michael Herndon
 Sent: Wednesday, September 07, 2011 5:12 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

  What version is going to make it to nuget? 2.9.4 or 2.9.4g?
 ooo totally forgot about nuget. we definitely need to get that setup.


 On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote:

  Since it includes some level of divergence from java I committed it to
 only
  2.9.4g branch.
 
  https://issues.apache.org/jira/browse/LUCENE-1930
  https://issues.apache.org/jira/browse/LUCENENET-431
 
  DIGY
 
  On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com
  wrote:
 
   Ok, core compiles, and all tests pass. We are now running long tests to
   measure memory usage among other things.
  
   There is one show stopper tho. There was a patch sent by Matt Warren
 for
   Spatial.Net, that doesn't seem to be in. See
   http://groups.google.com/group/ravendb/msg/7517f095810c48f3
  
   Any chance you can get it in to 2.9.4?
  
   On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com
   wrote:
  
Ok, great, we will run RavenDB on top of 2.9.4 in the next few days
 and
will let you know how it went.
   
   
On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon 
mhern...@wickedsoftware.net wrote:
   
I can't tell if the apache git mirror is updated via scheduler or
 from
commit hooks, but its generally stays close to being on par with
 svn.
 I'll
check next time I push something to svn.
   
But both of those items have made it to the mirror.
   
- michael
   
   
On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote:
   
 I don't know how often github mirror is updated.
 These are the original locations
 2.9.4
 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
 2.9.4g


   
  
 
 https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
 9_4g/

 Both versions include ThreadLocal fix + Signing.

 Thanks,
 DIGY



 -Original Message-
 From: itamar.synhers...@gmail.com [mailto:
  itamar.synhers...@gmail.com
   ]
On
 Behalf Of Itamar Syn-Hershko
 Sent: Tuesday, September 06, 2011 2:34 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 Not a problem, we will test RavenDB on a separate branch, also for
 potential
 memory leaks

 Digy, can you make sure the github mirror contains an updated
 2.9.4
   tag
I
 can pull from, which includes the latest ThreadLocal fix + the
   strongly
 signed patch applied to it?

 2011/9/6 Digy digyd...@gmail.com

  To avoid misunderstanding...
 
  Community==all Lucene.Net users
 
  DIGY
 
  -Original Message-
  From: Digy [mailto:digyd...@gmail.com]
  Sent: Monday, September 05, 2011 11:46 PM
  To: 'lucene-net-dev@lucene.apache.org'
  Subject: RE: [Lucene.Net] 2.9.4
 
  Not bad idea, but I would prefer community's feedback instead of
testing
  against all projects using Lucene.Net
  DIGY
 
  -Original Message-
  From: Matt Warren [mailto:mattd...@gmail.com]
  Sent: Monday, September 05, 2011 11:09 PM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
  If you want to test it against a large project you could take a
  look
at
 how
  RavenDB uses it?
 
  At the moment it's using 2.9.2 (
 
 


   
  
 
 https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
  )
  but if you were to recompile it against 2.9.4 and check that all
   it's
  unit-tests still run that would give you quite a large test
 case.
 
  On 5 September 2011 19:22, Prescott Nasser 
 geobmx...@hotmail.com
  
 wrote:
 
  
   Hey All,
  
   How do people feel about the 2.9.4 code base? I've been using
 it
   for
   sometime, for my use cases it's be excellent. Do we feel we
 are
ready
 to
   package this up and make it an official release? Or do we have
   some
 tasks
   left to take care of?
  
   ~Prescott
 



   
   
   
  
 

RE: [Lucene.Net] 2.9.4

[Digy]

Good news. Thanks Itamar.

DIGY

-Original Message-
From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com] On
Behalf Of Itamar Syn-Hershko
Sent: Saturday, September 10, 2011 8:23 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4

We have been running some extensive tests 30hrs now against the 2.9.4
branch, and did not detect any leaks. We will have it running a few more
days, if you wish to wait for more conclusive findings.

On Wed, Sep 7, 2011 at 5:07 PM, Prescott Nasser
geobmx...@hotmail.comwrote:

 2.9.4 would make it in I assume because that will be our next official
 release.


 Sent from my Windows Phone

 -Original Message-
 From: Michael Herndon
 Sent: Wednesday, September 07, 2011 5:12 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

  What version is going to make it to nuget? 2.9.4 or 2.9.4g?
 ooo totally forgot about nuget. we definitely need to get that setup.


 On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote:

  Since it includes some level of divergence from java I committed it to
 only
  2.9.4g branch.
 
  https://issues.apache.org/jira/browse/LUCENE-1930
  https://issues.apache.org/jira/browse/LUCENENET-431
 
  DIGY
 
  On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com
  wrote:
 
   Ok, core compiles, and all tests pass. We are now running long tests
to
   measure memory usage among other things.
  
   There is one show stopper tho. There was a patch sent by Matt Warren
 for
   Spatial.Net, that doesn't seem to be in. See
   http://groups.google.com/group/ravendb/msg/7517f095810c48f3
  
   Any chance you can get it in to 2.9.4?
  
   On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com
   wrote:
  
Ok, great, we will run RavenDB on top of 2.9.4 in the next few days
 and
will let you know how it went.
   
   
On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon 
mhern...@wickedsoftware.net wrote:
   
I can't tell if the apache git mirror is updated via scheduler or
 from
commit hooks, but its generally stays close to being on par with
 svn.
 I'll
check next time I push something to svn.
   
But both of those items have made it to the mirror.
   
- michael
   
   
On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote:
   
 I don't know how often github mirror is updated.
 These are the original locations
 2.9.4
 https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
 2.9.4g


   
  
 

https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
 9_4g/

 Both versions include ThreadLocal fix + Signing.

 Thanks,
 DIGY



 -Original Message-
 From: itamar.synhers...@gmail.com [mailto:
  itamar.synhers...@gmail.com
   ]
On
 Behalf Of Itamar Syn-Hershko
 Sent: Tuesday, September 06, 2011 2:34 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 Not a problem, we will test RavenDB on a separate branch, also
for
 potential
 memory leaks

 Digy, can you make sure the github mirror contains an updated
 2.9.4
   tag
I
 can pull from, which includes the latest ThreadLocal fix + the
   strongly
 signed patch applied to it?

 2011/9/6 Digy digyd...@gmail.com

  To avoid misunderstanding...
 
  Community==all Lucene.Net users
 
  DIGY
 
  -Original Message-
  From: Digy [mailto:digyd...@gmail.com]
  Sent: Monday, September 05, 2011 11:46 PM
  To: 'lucene-net-dev@lucene.apache.org'
  Subject: RE: [Lucene.Net] 2.9.4
 
  Not bad idea, but I would prefer community's feedback instead
of
testing
  against all projects using Lucene.Net
  DIGY
 
  -Original Message-
  From: Matt Warren [mailto:mattd...@gmail.com]
  Sent: Monday, September 05, 2011 11:09 PM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
  If you want to test it against a large project you could take a
  look
at
 how
  RavenDB uses it?
 
  At the moment it's using 2.9.2 (
 
 


   
  
 

https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
  )
  but if you were to recompile it against 2.9.4 and check that
all
   it's
  unit-tests still run that would give you quite a large test
 case.
 
  On 5 September 2011 19:22, Prescott Nasser 
 geobmx...@hotmail.com
  
 wrote:
 
  
   Hey All,
  
   How do people feel about the 2.9.4 code base? I've been using
 it
   for
   sometime, for my use cases it's be excellent. Do we feel we
 are
ready
 to
   package this up and make it an official release? Or do we
have
   some
 tasks
   left to take care of?
  
   ~Prescott

Re: [Lucene.Net] 2.9.4

[Itamar Syn-Hershko]

What version is going to make it to nuget? 2.9.4 or 2.9.4g?

2011/9/7 digy digy digyd...@gmail.com

 You are right. I forgot to add a patch related with type-casting.

 Summary of the long story:

 Since CharArraySet inherits from Hashtable, some unimplemented methods such
 as Add(object,object) refer to the base class(Hashtable) which is wrong.

 Also calling GetEnumerator() using the
 System.Collections.ICollection interface does result in Hashtable's
 GetEnumerator() being invoked. So an explicit typecast is needed for
 invoking CharArraySet.GetEnumerator()

 (As a result, a bad (but *almost* working) implementation.  It is rewritten
 in 2.9.4g)

 DIGY


 On Wed, Sep 7, 2011 at 4:11 AM, Prescott Nasser geobmx...@hotmail.com
 wrote:

 
  Also +1 - but I don't mind waiting to hear back regarding the RavenDB
 stuff
  - but we can prepare assuming it's all good.
 
 
 
  Digy can you elaborate on 414 (
  https://issues.apache.org/jira/browse/LUCENENET-414). I must not have
  understood the complaint/question as adding that one method to me doesn't
  seem to resolve the issue brought up
 
 
 
  Thanks,
 
  ~P
 
  
   From: digyd...@gmail.com
   To: lucene-net-dev@lucene.apache.org
   Date: Tue, 6 Sep 2011 23:14:37 +0300
   Subject: RE: [Lucene.Net] 2.9.4
  
   +1 for an official release.
   DIGY
  
   -Original Message-
   From: Prescott Nasser [mailto:geobmx...@hotmail.com]
   Sent: Monday, September 05, 2011 9:22 PM
   To: lucene-net-dev@lucene.apache.org;
 lucene-net-u...@lucene.apache.org
   Subject: [Lucene.Net] 2.9.4
  
  
   Hey All,
  
  
  
   How do people feel about the 2.9.4 code base? I've been using it for
   sometime, for my use cases it's be excellent. Do we feel we are ready
 to
   package this up and make it an official release? Or do we have some
 tasks
   left to take care of?
  
  
  
   ~Prescott =
   -
   Bu iletide virüs bulunamadı.
   AVG tarafından kontrol edildi - www.avg.com
   Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi:
  05.09.2011
  
 

Re: [Lucene.Net] 2.9.4

[digy digy]

Since it includes some level of divergence from java I committed it to only
2.9.4g branch.

https://issues.apache.org/jira/browse/LUCENE-1930
https://issues.apache.org/jira/browse/LUCENENET-431

DIGY

On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.comwrote:

 Ok, core compiles, and all tests pass. We are now running long tests to
 measure memory usage among other things.

 There is one show stopper tho. There was a patch sent by Matt Warren for
 Spatial.Net, that doesn't seem to be in. See
 http://groups.google.com/group/ravendb/msg/7517f095810c48f3

 Any chance you can get it in to 2.9.4?

 On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com
 wrote:

  Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and
  will let you know how it went.
 
 
  On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon 
  mhern...@wickedsoftware.net wrote:
 
  I can't tell if the apache git mirror is updated via scheduler or from
  commit hooks, but its generally stays close to being on par with svn.
   I'll
  check next time I push something to svn.
 
  But both of those items have made it to the mirror.
 
  - michael
 
 
  On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote:
 
   I don't know how often github mirror is updated.
   These are the original locations
   2.9.4  https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
   2.9.4g
  
  
 
 https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
   9_4g/
  
   Both versions include ThreadLocal fix + Signing.
  
   Thanks,
   DIGY
  
  
  
   -Original Message-
   From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com
 ]
  On
   Behalf Of Itamar Syn-Hershko
   Sent: Tuesday, September 06, 2011 2:34 AM
   To: lucene-net-dev@lucene.apache.org
   Subject: Re: [Lucene.Net] 2.9.4
  
   Not a problem, we will test RavenDB on a separate branch, also for
   potential
   memory leaks
  
   Digy, can you make sure the github mirror contains an updated 2.9.4
 tag
  I
   can pull from, which includes the latest ThreadLocal fix + the
 strongly
   signed patch applied to it?
  
   2011/9/6 Digy digyd...@gmail.com
  
To avoid misunderstanding...
   
Community==all Lucene.Net users
   
DIGY
   
-Original Message-
From: Digy [mailto:digyd...@gmail.com]
Sent: Monday, September 05, 2011 11:46 PM
To: 'lucene-net-dev@lucene.apache.org'
Subject: RE: [Lucene.Net] 2.9.4
   
Not bad idea, but I would prefer community's feedback instead of
  testing
against all projects using Lucene.Net
DIGY
   
-Original Message-
From: Matt Warren [mailto:mattd...@gmail.com]
Sent: Monday, September 05, 2011 11:09 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4
   
If you want to test it against a large project you could take a look
  at
   how
RavenDB uses it?
   
At the moment it's using 2.9.2 (
   
   
  
  
 
 https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
)
but if you were to recompile it against 2.9.4 and check that all
 it's
unit-tests still run that would give you quite a large test case.
   
On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com
   wrote:
   

 Hey All,

 How do people feel about the 2.9.4 code base? I've been using it
 for
 sometime, for my use cases it's be excellent. Do we feel we are
  ready
   to
 package this up and make it an official release? Or do we have
 some
   tasks
 left to take care of?

 ~Prescott
   
  
  
  
 
 
 

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

 What version is going to make it to nuget? 2.9.4 or 2.9.4g?
ooo totally forgot about nuget. we definitely need to get that setup.


On Wed, Sep 7, 2011 at 6:46 AM, digy digy digyd...@gmail.com wrote:

 Since it includes some level of divergence from java I committed it to only
 2.9.4g branch.

 https://issues.apache.org/jira/browse/LUCENE-1930
 https://issues.apache.org/jira/browse/LUCENENET-431

 DIGY

 On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com
 wrote:

  Ok, core compiles, and all tests pass. We are now running long tests to
  measure memory usage among other things.
 
  There is one show stopper tho. There was a patch sent by Matt Warren for
  Spatial.Net, that doesn't seem to be in. See
  http://groups.google.com/group/ravendb/msg/7517f095810c48f3
 
  Any chance you can get it in to 2.9.4?
 
  On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com
  wrote:
 
   Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and
   will let you know how it went.
  
  
   On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon 
   mhern...@wickedsoftware.net wrote:
  
   I can't tell if the apache git mirror is updated via scheduler or from
   commit hooks, but its generally stays close to being on par with svn.
I'll
   check next time I push something to svn.
  
   But both of those items have made it to the mirror.
  
   - michael
  
  
   On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote:
  
I don't know how often github mirror is updated.
These are the original locations
2.9.4  https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
2.9.4g
   
   
  
 
 https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
9_4g/
   
Both versions include ThreadLocal fix + Signing.
   
Thanks,
DIGY
   
   
   
-Original Message-
From: itamar.synhers...@gmail.com [mailto:
 itamar.synhers...@gmail.com
  ]
   On
Behalf Of Itamar Syn-Hershko
Sent: Tuesday, September 06, 2011 2:34 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4
   
Not a problem, we will test RavenDB on a separate branch, also for
potential
memory leaks
   
Digy, can you make sure the github mirror contains an updated 2.9.4
  tag
   I
can pull from, which includes the latest ThreadLocal fix + the
  strongly
signed patch applied to it?
   
2011/9/6 Digy digyd...@gmail.com
   
 To avoid misunderstanding...

 Community==all Lucene.Net users

 DIGY

 -Original Message-
 From: Digy [mailto:digyd...@gmail.com]
 Sent: Monday, September 05, 2011 11:46 PM
 To: 'lucene-net-dev@lucene.apache.org'
 Subject: RE: [Lucene.Net] 2.9.4

 Not bad idea, but I would prefer community's feedback instead of
   testing
 against all projects using Lucene.Net
 DIGY

 -Original Message-
 From: Matt Warren [mailto:mattd...@gmail.com]
 Sent: Monday, September 05, 2011 11:09 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 If you want to test it against a large project you could take a
 look
   at
how
 RavenDB uses it?

 At the moment it's using 2.9.2 (


   
   
  
 
 https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
 )
 but if you were to recompile it against 2.9.4 and check that all
  it's
 unit-tests still run that would give you quite a large test case.

 On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com
 
wrote:

 
  Hey All,
 
  How do people feel about the 2.9.4 code base? I've been using it
  for
  sometime, for my use cases it's be excellent. Do we feel we are
   ready
to
  package this up and make it an official release? Or do we have
  some
tasks
  left to take care of?
 
  ~Prescott

   
   
   
  
  
  
 

Re: [Lucene.Net] 2.9.4

[Itamar Syn-Hershko]

I see. It is merely a bug fix, and we would be happy to see it in 2.9.4 too
- so we can get it from nuget instead of forking it

On Wed, Sep 7, 2011 at 1:46 PM, digy digy digyd...@gmail.com wrote:

 Since it includes some level of divergence from java I committed it to only
 2.9.4g branch.

 https://issues.apache.org/jira/browse/LUCENE-1930
 https://issues.apache.org/jira/browse/LUCENENET-431

 DIGY

 On Wed, Sep 7, 2011 at 1:03 PM, Itamar Syn-Hershko ita...@code972.com
 wrote:

  Ok, core compiles, and all tests pass. We are now running long tests to
  measure memory usage among other things.
 
  There is one show stopper tho. There was a patch sent by Matt Warren for
  Spatial.Net, that doesn't seem to be in. See
  http://groups.google.com/group/ravendb/msg/7517f095810c48f3
 
  Any chance you can get it in to 2.9.4?
 
  On Wed, Sep 7, 2011 at 1:01 AM, Itamar Syn-Hershko ita...@code972.com
  wrote:
 
   Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and
   will let you know how it went.
  
  
   On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon 
   mhern...@wickedsoftware.net wrote:
  
   I can't tell if the apache git mirror is updated via scheduler or from
   commit hooks, but its generally stays close to being on par with svn.
I'll
   check next time I push something to svn.
  
   But both of those items have made it to the mirror.
  
   - michael
  
  
   On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote:
  
I don't know how often github mirror is updated.
These are the original locations
2.9.4  https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
2.9.4g
   
   
  
 
 https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
9_4g/
   
Both versions include ThreadLocal fix + Signing.
   
Thanks,
DIGY
   
   
   
-Original Message-
From: itamar.synhers...@gmail.com [mailto:
 itamar.synhers...@gmail.com
  ]
   On
Behalf Of Itamar Syn-Hershko
Sent: Tuesday, September 06, 2011 2:34 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4
   
Not a problem, we will test RavenDB on a separate branch, also for
potential
memory leaks
   
Digy, can you make sure the github mirror contains an updated 2.9.4
  tag
   I
can pull from, which includes the latest ThreadLocal fix + the
  strongly
signed patch applied to it?
   
2011/9/6 Digy digyd...@gmail.com
   
 To avoid misunderstanding...

 Community==all Lucene.Net users

 DIGY

 -Original Message-
 From: Digy [mailto:digyd...@gmail.com]
 Sent: Monday, September 05, 2011 11:46 PM
 To: 'lucene-net-dev@lucene.apache.org'
 Subject: RE: [Lucene.Net] 2.9.4

 Not bad idea, but I would prefer community's feedback instead of
   testing
 against all projects using Lucene.Net
 DIGY

 -Original Message-
 From: Matt Warren [mailto:mattd...@gmail.com]
 Sent: Monday, September 05, 2011 11:09 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 If you want to test it against a large project you could take a
 look
   at
how
 RavenDB uses it?

 At the moment it's using 2.9.2 (


   
   
  
 
 https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
 )
 but if you were to recompile it against 2.9.4 and check that all
  it's
 unit-tests still run that would give you quite a large test case.

 On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com
 
wrote:

 
  Hey All,
 
  How do people feel about the 2.9.4 code base? I've been using it
  for
  sometime, for my use cases it's be excellent. Do we feel we are
   ready
to
  package this up and make it an official release? Or do we have
  some
tasks
  left to take care of?
 
  ~Prescott

   
   
   
  
  
  
 

RE: [Lucene.Net] 2.9.4

[Digy]

I don't know how often github mirror is updated.
These are the original locations 
2.9.4  https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/ 
2.9.4g
https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
9_4g/

Both versions include ThreadLocal fix + Signing.

Thanks,
DIGY



-Original Message-
From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com] On
Behalf Of Itamar Syn-Hershko
Sent: Tuesday, September 06, 2011 2:34 AM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4

Not a problem, we will test RavenDB on a separate branch, also for potential
memory leaks

Digy, can you make sure the github mirror contains an updated 2.9.4 tag I
can pull from, which includes the latest ThreadLocal fix + the strongly
signed patch applied to it?

2011/9/6 Digy digyd...@gmail.com

 To avoid misunderstanding...

 Community==all Lucene.Net users

 DIGY

 -Original Message-
 From: Digy [mailto:digyd...@gmail.com]
 Sent: Monday, September 05, 2011 11:46 PM
 To: 'lucene-net-dev@lucene.apache.org'
 Subject: RE: [Lucene.Net] 2.9.4

 Not bad idea, but I would prefer community's feedback instead of testing
 against all projects using Lucene.Net
 DIGY

 -Original Message-
 From: Matt Warren [mailto:mattd...@gmail.com]
 Sent: Monday, September 05, 2011 11:09 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 If you want to test it against a large project you could take a look at
how
 RavenDB uses it?

 At the moment it's using 2.9.2 (


https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
 )
 but if you were to recompile it against 2.9.4 and check that all it's
 unit-tests still run that would give you quite a large test case.

 On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote:

 
  Hey All,
 
  How do people feel about the 2.9.4 code base? I've been using it for
  sometime, for my use cases it's be excellent. Do we feel we are ready to
  package this up and make it an official release? Or do we have some
tasks
  left to take care of?
 
  ~Prescott

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Also +1 - but I don't mind waiting to hear back regarding the RavenDB stuff - 
but we can prepare assuming it's all good.

 

Digy can you elaborate on 414 
(https://issues.apache.org/jira/browse/LUCENENET-414). I must not have 
understood the complaint/question as adding that one method to me doesn't seem 
to resolve the issue brought up

 

Thanks,

~P


 From: digyd...@gmail.com
 To: lucene-net-dev@lucene.apache.org
 Date: Tue, 6 Sep 2011 23:14:37 +0300
 Subject: RE: [Lucene.Net] 2.9.4

 +1 for an official release.
 DIGY

 -Original Message-
 From: Prescott Nasser [mailto:geobmx...@hotmail.com]
 Sent: Monday, September 05, 2011 9:22 PM
 To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
 Subject: [Lucene.Net] 2.9.4


 Hey All,



 How do people feel about the 2.9.4 code base? I've been using it for
 sometime, for my use cases it's be excellent. Do we feel we are ready to
 package this up and make it an official release? Or do we have some tasks
 left to take care of?



 ~Prescott =
 -
 Bu iletide virüs bulunamadı.
 AVG tarafından kontrol edildi - www.avg.com
 Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
 

Re: [Lucene.Net] 2.9.4

[Itamar Syn-Hershko]

Ok, great, we will run RavenDB on top of 2.9.4 in the next few days and will
let you know how it went.

On Tue, Sep 6, 2011 at 8:59 PM, Michael Herndon mhern...@wickedsoftware.net
 wrote:

 I can't tell if the apache git mirror is updated via scheduler or from
 commit hooks, but its generally stays close to being on par with svn.  I'll
 check next time I push something to svn.

 But both of those items have made it to the mirror.

 - michael


 On Tue, Sep 6, 2011 at 1:44 PM, Digy digyd...@gmail.com wrote:

  I don't know how often github mirror is updated.
  These are the original locations
  2.9.4  https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/
  2.9.4g
 
 
 https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_
  9_4g/
 
  Both versions include ThreadLocal fix + Signing.
 
  Thanks,
  DIGY
 
 
 
  -Original Message-
  From: itamar.synhers...@gmail.com [mailto:itamar.synhers...@gmail.com]
 On
  Behalf Of Itamar Syn-Hershko
  Sent: Tuesday, September 06, 2011 2:34 AM
  To: lucene-net-dev@lucene.apache.org
  Subject: Re: [Lucene.Net] 2.9.4
 
  Not a problem, we will test RavenDB on a separate branch, also for
  potential
  memory leaks
 
  Digy, can you make sure the github mirror contains an updated 2.9.4 tag I
  can pull from, which includes the latest ThreadLocal fix + the strongly
  signed patch applied to it?
 
  2011/9/6 Digy digyd...@gmail.com
 
   To avoid misunderstanding...
  
   Community==all Lucene.Net users
  
   DIGY
  
   -Original Message-
   From: Digy [mailto:digyd...@gmail.com]
   Sent: Monday, September 05, 2011 11:46 PM
   To: 'lucene-net-dev@lucene.apache.org'
   Subject: RE: [Lucene.Net] 2.9.4
  
   Not bad idea, but I would prefer community's feedback instead of
 testing
   against all projects using Lucene.Net
   DIGY
  
   -Original Message-
   From: Matt Warren [mailto:mattd...@gmail.com]
   Sent: Monday, September 05, 2011 11:09 PM
   To: lucene-net-dev@lucene.apache.org
   Subject: Re: [Lucene.Net] 2.9.4
  
   If you want to test it against a large project you could take a look at
  how
   RavenDB uses it?
  
   At the moment it's using 2.9.2 (
  
  
 
 
 https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
   )
   but if you were to recompile it against 2.9.4 and check that all it's
   unit-tests still run that would give you quite a large test case.
  
   On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com
  wrote:
  
   
Hey All,
   
How do people feel about the 2.9.4 code base? I've been using it for
sometime, for my use cases it's be excellent. Do we feel we are ready
  to
package this up and make it an official release? Or do we have some
  tasks
left to take care of?
   
~Prescott
  
 
 
 

Re: [Lucene.Net] 2.9.4

[Michael Herndon]

Should we put together a quick release checklist ?

 * I know that jira 407 mentions putting out a 2.9.2 build that is signed
when releasing 2.9.4

 * We should be able to build a chm  doc website using sandcastle.The
downside is the website that gets built now requires asp.net instead of just
vanilla HTML and I have yet to find an option that allows just HTML.
Depending on what we do with this, we would need to remove the link to the
docs in the README file inside of trunk.

* Stefan Bodewig might still be away and I think we need his vote on the
release when the time comes. (correct me, because I could be uber wrong).

If there is anything that requires work and you think I can help with in
order to get this release out the door, just let me know.

- Michael



On Tue, Sep 6, 2011 at 9:11 PM, Prescott Nasser geobmx...@hotmail.comwrote:


 Also +1 - but I don't mind waiting to hear back regarding the RavenDB stuff
 - but we can prepare assuming it's all good.



 Digy can you elaborate on 414 (
 https://issues.apache.org/jira/browse/LUCENENET-414). I must not have
 understood the complaint/question as adding that one method to me doesn't
 seem to resolve the issue brought up



 Thanks,

 ~P

 
  From: digyd...@gmail.com
  To: lucene-net-dev@lucene.apache.org
  Date: Tue, 6 Sep 2011 23:14:37 +0300
  Subject: RE: [Lucene.Net] 2.9.4
 
  +1 for an official release.
  DIGY
 
  -Original Message-
  From: Prescott Nasser [mailto:geobmx...@hotmail.com]
  Sent: Monday, September 05, 2011 9:22 PM
  To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
  Subject: [Lucene.Net] 2.9.4
 
 
  Hey All,
 
 
 
  How do people feel about the 2.9.4 code base? I've been using it for
  sometime, for my use cases it's be excellent. Do we feel we are ready to
  package this up and make it an official release? Or do we have some tasks
  left to take care of?
 
 
 
  ~Prescott =
  -
  Bu iletide virüs bulunamadı.
  AVG tarafından kontrol edildi - www.avg.com
  Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi:
 05.09.2011
 

Re: [Lucene.Net] 2.9.4

[Stefan Bodewig]

On 2011-09-07, Michael Herndon wrote:

 Stefan Bodewig might still be away

He is back ;-)

 and I think we need his vote on the release when the time
 comes. (correct me, because I could be uber wrong).

For the release you need three +1s by Incubator PMC members.  After
voting here a second vote will happen on the general list where the
missing IPMC member votes can be collected.  Of course it will be easier
if the mentors (Benson, Gianugo and myself in this case) have already
voted.

Stefan

RE: [Lucene.Net] 2.9.4

[Digy]

To avoid misunderstanding...

Community==all Lucene.Net users

DIGY

-Original Message-
From: Digy [mailto:digyd...@gmail.com] 
Sent: Monday, September 05, 2011 11:46 PM
To: 'lucene-net-dev@lucene.apache.org'
Subject: RE: [Lucene.Net] 2.9.4

Not bad idea, but I would prefer community's feedback instead of testing
against all projects using Lucene.Net
DIGY

-Original Message-
From: Matt Warren [mailto:mattd...@gmail.com] 
Sent: Monday, September 05, 2011 11:09 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] 2.9.4

If you want to test it against a large project you could take a look at how
RavenDB uses it?

At the moment it's using 2.9.2 (
https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
)
but if you were to recompile it against 2.9.4 and check that all it's
unit-tests still run that would give you quite a large test case.

On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote:


 Hey All,

 How do people feel about the 2.9.4 code base? I've been using it for
 sometime, for my use cases it's be excellent. Do we feel we are ready to
 package this up and make it an official release? Or do we have some tasks
 left to take care of?

 ~Prescott

-
Bu iletide virüs bulunamadı.
AVG tarafından kontrol edildi - www.avg.com
Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011

RE: [Lucene.Net] 2.9.4

[Prescott Nasser]

Yeah, I looked at it as 2.9.4 has been around a while, I've been using it for a 
while, and I assume others have as well, and we haven't had any complaints (few 
exceptions). 

 

I hope people aren't waiting for a last call to provide feedback. It should 
be continous. When it dies down, I assume issues are shaken out and things are 
somewhat vetted.

 

~P

 



 From: digyd...@gmail.com
 To: lucene-net-dev@lucene.apache.org
 Date: Tue, 6 Sep 2011 00:48:02 +0300
 Subject: RE: [Lucene.Net] 2.9.4

 To avoid misunderstanding...

 Community==all Lucene.Net users

 DIGY

 -Original Message-
 From: Digy [mailto:digyd...@gmail.com]
 Sent: Monday, September 05, 2011 11:46 PM
 To: 'lucene-net-dev@lucene.apache.org'
 Subject: RE: [Lucene.Net] 2.9.4

 Not bad idea, but I would prefer community's feedback instead of testing
 against all projects using Lucene.Net
 DIGY

 -Original Message-
 From: Matt Warren [mailto:mattd...@gmail.com]
 Sent: Monday, September 05, 2011 11:09 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 If you want to test it against a large project you could take a look at how
 RavenDB uses it?

 At the moment it's using 2.9.2 (
 https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
 )
 but if you were to recompile it against 2.9.4 and check that all it's
 unit-tests still run that would give you quite a large test case.

 On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote:

 
  Hey All,
 
  How do people feel about the 2.9.4 code base? I've been using it for
  sometime, for my use cases it's be excellent. Do we feel we are ready to
  package this up and make it an official release? Or do we have some tasks
  left to take care of?
 
  ~Prescott

 -
 Bu iletide virüs bulunamadı.
 AVG tarafından kontrol edildi - www.avg.com
 Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi: 05.09.2011
 

Re: [Lucene.Net] 2.9.4

[Itamar Syn-Hershko]

Not a problem, we will test RavenDB on a separate branch, also for potential
memory leaks

Digy, can you make sure the github mirror contains an updated 2.9.4 tag I
can pull from, which includes the latest ThreadLocal fix + the strongly
signed patch applied to it?

2011/9/6 Digy digyd...@gmail.com

 To avoid misunderstanding...

 Community==all Lucene.Net users

 DIGY

 -Original Message-
 From: Digy [mailto:digyd...@gmail.com]
 Sent: Monday, September 05, 2011 11:46 PM
 To: 'lucene-net-dev@lucene.apache.org'
 Subject: RE: [Lucene.Net] 2.9.4

 Not bad idea, but I would prefer community's feedback instead of testing
 against all projects using Lucene.Net
 DIGY

 -Original Message-
 From: Matt Warren [mailto:mattd...@gmail.com]
 Sent: Monday, September 05, 2011 11:09 PM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] 2.9.4

 If you want to test it against a large project you could take a look at how
 RavenDB uses it?

 At the moment it's using 2.9.2 (

 https://github.com/ayende/ravendb/tree/master/SharedLibs/Sources/Lucene2.9.2
 )
 but if you were to recompile it against 2.9.4 and check that all it's
 unit-tests still run that would give you quite a large test case.

 On 5 September 2011 19:22, Prescott Nasser geobmx...@hotmail.com wrote:

 
  Hey All,
 
  How do people feel about the 2.9.4 code base? I've been using it for
  sometime, for my use cases it's be excellent. Do we feel we are ready to
  package this up and make it an official release? Or do we have some tasks
  left to take care of?
 
  ~Prescott

 -
 Bu iletide virüs bulunamadı.
 AVG tarafından kontrol edildi - www.avg.com
 Sürüm: 2012.0.1796 / Virüs Veritabanı: 2082/4478 - Sürüm Tarihi:
 05.09.2011

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Sergey Mirvoda]

+1

On Thu, May 12, 2011 at 6:03 AM, Gregory Bell gregory.b...@advansyscorp.com
 wrote:

 +1

  Troy Howard thowar...@gmail.com 10/05/2011 7:44 AM 
 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 .Net 4.0 framework target vs 2.0 or 3.5...

 Thanks,
 Troy


 On Mon, May 9, 2011 at 2:40 PM, Aaron Powell m...@aaron-powell.com wrote:
  +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
 
  http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell |
 MSN: aaz...@hotmail.com
 
  -Original Message-
  From: Troy Howard [mailto:thowar...@gmail.com]
  Sent: Tuesday, 10 May 2011 6:05 AM
  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 votes regarding the topic of .Net Framework support.
 
  The question on the table is:
 
  Should Apache Lucene.Net 2.9.4 be the last release which supports the
 .Net 2.0 Framework?
 
  Some options are:
 
  [+1] - Yes, move forward to the latest .Net Framework version, and drop
 support for 2.0 completely. New features and performance are more important
 than backwards compatibility.
  [0] - Yes, focus on the latest .Net Framework, but also include patches
 and/or preprocessor directives and conditional compilation blocks to include
 support for 2.0 when needed. New features, performance, and backwards
 compatibility are all equally important and it's worth the additional
 complexity and coding work to meet all of those goals.
  [-1] No, .Net Framework 2.0 should remain our target platform. Backwards
 compatibility is more important than new features and performance.
 
 
  This vote is not limited to the Apache Lucene.Net IPMC. All
 users/contributors/committers/mailing list lurkers are welcome to cast their
 votes with an equal weight. This has been cross posted to both the dev and
 user mailing lists.
 
  Thanks,
  Troy
 




-- 
--Regards, Sergey Mirvoda

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Vincent DARON]

Do it, if you need it. +1



Le 10/05/11 20:02, Lombard, Scott a écrit :

+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 votes regarding the topic of .Net Framework support.

The question on the table is:

Should Apache Lucene.Net 2.9.4 be the last release which supports the
.Net 2.0 Framework?

Some options are:

[+1] - Yes, move forward to the latest .Net Framework version, and drop
support for 2.0 completely. New features and performance are more
important
than backwards compatibility.
[0] - Yes, focus on the latest .Net Framework, but also include patches
and/or preprocessor directives and conditional compilation blocks to
include
support for 2.0 when needed. New features, performance, and backwards
compatibility are all equally important and it's worth the additional
complexity and coding work to meet all of those goals.
[-1] No, .Net Framework 2.0 should remain our target platform. Backwards
compatibility is more important than new features and performance.


This vote is not limited to the Apache Lucene.Net IPMC. All
users/contributors/committers/mailing list lurkers are welcome to cast
their
votes with an equal weight. This has been cross posted to both the dev and
user mailing lists.

Thanks,
Troy


This message (and any associated files) is intended only for the
use of the individual or entity to which it is addressed and may
contain information that is confidential, subject to copyright or
constitutes a trade secret. If you are not the intended recipient
you are hereby notified that any dissemination, copying or
distribution of this message, or files associated with this message,
is strictly prohibited. If you have received this message in error,
please notify us immediately by replying to the message and deleting
it from your computer.  Thank you, King Industries, Inc.

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Gregory Bell]

+1

 Troy Howard thowar...@gmail.com 10/05/2011 7:44 AM 
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 .Net 4.0 framework target vs 2.0 or 3.5...

Thanks,
Troy


On Mon, May 9, 2011 at 2:40 PM, Aaron Powell m...@aaron-powell.com wrote:
 +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

 http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | MSN: 
 aaz...@hotmail.com

 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Tuesday, 10 May 2011 6:05 AM
 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 votes regarding the topic of .Net Framework support.

 The question on the table is:

 Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 
 2.0 Framework?

 Some options are:

 [+1] - Yes, move forward to the latest .Net Framework version, and drop 
 support for 2.0 completely. New features and performance are more important 
 than backwards compatibility.
 [0] - Yes, focus on the latest .Net Framework, but also include patches 
 and/or preprocessor directives and conditional compilation blocks to include 
 support for 2.0 when needed. New features, performance, and backwards 
 compatibility are all equally important and it's worth the additional 
 complexity and coding work to meet all of those goals.
 [-1] No, .Net Framework 2.0 should remain our target platform. Backwards 
 compatibility is more important than new features and performance.


 This vote is not limited to the Apache Lucene.Net IPMC. All 
 users/contributors/committers/mailing list lurkers are welcome to cast their 
 votes with an equal weight. This has been cross posted to both the dev and 
 user mailing lists.

 Thanks,
 Troy

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Amanuel Workneh]

+1 (According to Digy's suggestion)


On Mon, May 9, 2011 at 10:04 PM, Troy Howard thowar...@gmail.com wrote:
 All,

 Please cast your votes regarding the topic of .Net Framework support.

 The question on the table is:

 Should Apache Lucene.Net 2.9.4 be the last release which supports the
 .Net 2.0 Framework?

 Some options are:

 [+1] - Yes, move forward to the latest .Net Framework version, and drop
 support for 2.0 completely. New features and performance are more important
 than backwards compatibility.
 [0] - Yes, focus on the latest .Net Framework, but also include patches
 and/or preprocessor directives and conditional compilation blocks to include
 support for 2.0 when needed. New features, performance, and backwards
 compatibility are all equally important and it's worth the additional
 complexity and coding work to meet all of those goals.
 [-1] No, .Net Framework 2.0 should remain our target platform. Backwards
 compatibility is more important than new features and performance.


 This vote is not limited to the Apache Lucene.Net IPMC. All
 users/contributors/committers/mailing list lurkers are welcome to cast their
 votes with an equal weight. This has been cross posted to both the dev and
 user mailing lists.

 Thanks,
 Troy

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Simone Chiaretta]

+1
one option is that we could go forward with .NET 4, but still keep a fix
branch that keeps the current .NET 2 based version free from bugs and
security issues that ppl report.

Simone

On Tue, May 10, 2011 at 9:18 AM, Amanuel Workneh ma...@rotselleri.comwrote:

 +1 (According to Digy's suggestion)


 On Mon, May 9, 2011 at 10:04 PM, Troy Howard thowar...@gmail.com wrote:
  All,
 
  Please cast your votes regarding the topic of .Net Framework support.
 
  The question on the table is:
 
  Should Apache Lucene.Net 2.9.4 be the last release which supports the
  .Net 2.0 Framework?
 
  Some options are:
 
  [+1] - Yes, move forward to the latest .Net Framework version, and drop
  support for 2.0 completely. New features and performance are more
 important
  than backwards compatibility.
  [0] - Yes, focus on the latest .Net Framework, but also include patches
  and/or preprocessor directives and conditional compilation blocks to
 include
  support for 2.0 when needed. New features, performance, and backwards
  compatibility are all equally important and it's worth the additional
  complexity and coding work to meet all of those goals.
  [-1] No, .Net Framework 2.0 should remain our target platform. Backwards
  compatibility is more important than new features and performance.
 
 
  This vote is not limited to the Apache Lucene.Net IPMC. All
  users/contributors/committers/mailing list lurkers are welcome to cast
 their
  votes with an equal weight. This has been cross posted to both the dev
 and
  user mailing lists.
 
  Thanks,
  Troy
 




-- 
Simone Chiaretta
Microsoft MVP ASP.NET - ASPInsider
Blog: http://codeclimber.net.nz
RSS: http://feeds2.feedburner.com/codeclimber
twitter: @simonech

Any sufficiently advanced technology is indistinguishable from magic
Life is short, play hard

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Prescott Nasser]

This is my +1 as well






 Date: Tue, 10 May 2011 09:24:07 +0200
 From: simone.chiare...@gmail.com
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache 
 Lucene.Net 2.9.4

 +1
 one option is that we could go forward with .NET 4, but still keep a fix
 branch that keeps the current .NET 2 based version free from bugs and
 security issues that ppl report.

 Simone

 On Tue, May 10, 2011 at 9:18 AM, Amanuel Workneh wrote:

  +1 (According to Digy's suggestion)
 
 
  On Mon, May 9, 2011 at 10:04 PM, Troy Howard wrote:
   All,
  
   Please cast your votes regarding the topic of .Net Framework support.
  
   The question on the table is:
  
   Should Apache Lucene.Net 2.9.4 be the last release which supports the
   .Net 2.0 Framework?
  
   Some options are:
  
   [+1] - Yes, move forward to the latest .Net Framework version, and drop
   support for 2.0 completely. New features and performance are more
  important
   than backwards compatibility.
   [0] - Yes, focus on the latest .Net Framework, but also include patches
   and/or preprocessor directives and conditional compilation blocks to
  include
   support for 2.0 when needed. New features, performance, and backwards
   compatibility are all equally important and it's worth the additional
   complexity and coding work to meet all of those goals.
   [-1] No, .Net Framework 2.0 should remain our target platform. Backwards
   compatibility is more important than new features and performance.
  
  
   This vote is not limited to the Apache Lucene.Net IPMC. All
   users/contributors/committers/mailing list lurkers are welcome to cast
  their
   votes with an equal weight. This has been cross posted to both the dev
  and
   user mailing lists.
  
   Thanks,
   Troy
  
 



 --
 Simone Chiaretta
 Microsoft MVP ASP.NET - ASPInsider
 Blog: http://codeclimber.net.nz
 RSS: http://feeds2.feedburner.com/codeclimber
 twitter: @simonech

 Any sufficiently advanced technology is indistinguishable from magic
 Life is short, play hard  

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Daniele Fusi]

+1, go for .NET 4...
Thanks

-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com]
Sent: 09 May 2011 21:05
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 votes regarding the topic of .Net Framework support.

The question on the table is:

Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 
Framework?

Some options are:

[+1] - Yes, move forward to the latest .Net Framework version, and drop support 
for 2.0 completely. New features and performance are more important than 
backwards compatibility.
[0] - Yes, focus on the latest .Net Framework, but also include patches and/or 
preprocessor directives and conditional compilation blocks to include support 
for 2.0 when needed. New features, performance, and backwards compatibility are 
all equally important and it's worth the additional complexity and coding work 
to meet all of those goals.
[-1] No, .Net Framework 2.0 should remain our target platform. Backwards 
compatibility is more important than new features and performance.


This vote is not limited to the Apache Lucene.Net IPMC. All 
users/contributors/committers/mailing list lurkers are welcome to cast their 
votes with an equal weight. This has been cross posted to both the dev and user 
mailing lists.

Thanks,
Troy

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Christopher Currens]

+1, but I'm partial to 0 if the demand is there for it.  I don't mind
keeping up support for 2.0, in a separate branch, for a set amount of time.

On Tue, May 10, 2011 at 2:01 AM, Moray McConnachie 
mmcco...@oxford-analytica.com wrote:


 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


 Aaron, I think the move to 4.0 is actually to stop supporting 3.5 as
 well judging by later emails...

 Moray
 -
 Moray McConnachie
 Director of IT+44 1865 261 600
 Oxford Analytica  http://www.oxan.com

 -
 Disclaimer

 This message and any attachments are confidential and/or privileged. If
 this has been sent to you in error, please do not use, retain or disclose
 them, and contact the sender as soon as possible.

 Oxford Analytica Ltd
 Registered in England: No. 1196703
 5 Alfred Street, Oxford
 United Kingdom, OX1 4EH
 -

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Wyatt Barnett]

+1, burn the ships.

On Tue, May 10, 2011 at 12:43 PM, Christopher Currens
currens.ch...@gmail.com wrote:
 +1, but I'm partial to 0 if the demand is there for it.  I don't mind
 keeping up support for 2.0, in a separate branch, for a set amount of time.

 On Tue, May 10, 2011 at 2:01 AM, Moray McConnachie 
 mmcco...@oxford-analytica.com wrote:


 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


 Aaron, I think the move to 4.0 is actually to stop supporting 3.5 as
 well judging by later emails...

 Moray
 -
 Moray McConnachie
 Director of IT    +44 1865 261 600
 Oxford Analytica  http://www.oxan.com

 -
 Disclaimer

 This message and any attachments are confidential and/or privileged. If
 this has been sent to you in error, please do not use, retain or disclose
 them, and contact the sender as soon as possible.

 Oxford Analytica Ltd
 Registered in England: No. 1196703
 5 Alfred Street, Oxford
 United Kingdom, OX1 4EH
 -

[Lucene.Net] OT: Wyatt's expression was - RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Nicholas Paldino [.NET/C# MVP]]

I've cast my vote already, but +1 to Wyatt's expression

-Original Message-
From: Wyatt Barnett [mailto:wyatt.barn...@gmail.com] 
Sent: Tuesday, May 10, 2011 12:46 PM
To: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache
Lucene.Net 2.9.4

+1, burn the ships.

On Tue, May 10, 2011 at 12:43 PM, Christopher Currens
currens.ch...@gmail.com wrote:
 +1, but I'm partial to 0 if the demand is there for it.  I don't mind
 keeping up support for 2.0, in a separate branch, for a set amount of
time.

 On Tue, May 10, 2011 at 2:01 AM, Moray McConnachie 
 mmcco...@oxford-analytica.com wrote:


 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


 Aaron, I think the move to 4.0 is actually to stop supporting 3.5 as
 well judging by later emails...

 Moray
 -
 Moray McConnachie
 Director of IT    +44 1865 261 600
 Oxford Analytica  http://www.oxan.com

 -
 Disclaimer

 This message and any attachments are confidential and/or privileged. If
 this has been sent to you in error, please do not use, retain or disclose
 them, and contact the sender as soon as possible.

 Oxford Analytica Ltd
 Registered in England: No. 1196703
 5 Alfred Street, Oxford
 United Kingdom, OX1 4EH
 -

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Digy]

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 performance are more important
than backwards compatibility.

DIGY

-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com] 
Sent: Monday, May 09, 2011 11: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 votes regarding the topic of .Net Framework support.

The question on the table is:

Should Apache Lucene.Net 2.9.4 be the last release which supports the
.Net 2.0 Framework?

Some options are:

[+1] - Yes, move forward to the latest .Net Framework version, and drop
support for 2.0 completely. New features and performance are more important
than backwards compatibility.
[0] - Yes, focus on the latest .Net Framework, but also include patches
and/or preprocessor directives and conditional compilation blocks to include
support for 2.0 when needed. New features, performance, and backwards
compatibility are all equally important and it's worth the additional
complexity and coding work to meet all of those goals.
[-1] No, .Net Framework 2.0 should remain our target platform. Backwards
compatibility is more important than new features and performance.


This vote is not limited to the Apache Lucene.Net IPMC. All
users/contributors/committers/mailing list lurkers are welcome to cast their
votes with an equal weight. This has been cross posted to both the dev and
user mailing lists.

Thanks,
Troy

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Digy]

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 [mailto:thowar...@gmail.com] 
Sent: Monday, May 09, 2011 11: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 votes regarding the topic of .Net Framework support.

The question on the table is:

Should Apache Lucene.Net 2.9.4 be the last release which supports the
.Net 2.0 Framework?

Some options are:

[+1] - Yes, move forward to the latest .Net Framework version, and drop
support for 2.0 completely. New features and performance are more important
than backwards compatibility.
[0] - Yes, focus on the latest .Net Framework, but also include patches
and/or preprocessor directives and conditional compilation blocks to include
support for 2.0 when needed. New features, performance, and backwards
compatibility are all equally important and it's worth the additional
complexity and coding work to meet all of those goals.
[-1] No, .Net Framework 2.0 should remain our target platform. Backwards
compatibility is more important than new features and performance.


This vote is not limited to the Apache Lucene.Net IPMC. All
users/contributors/committers/mailing list lurkers are welcome to cast their
votes with an equal weight. This has been cross posted to both the dev and
user mailing lists.

Thanks,
Troy

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Digy]

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: lucene-net-dev@lucene.apache.org
Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache 
Lucene.Net 2.9.4

We could specify a new version starting with 2.9.4g and call it 2.9.5
... Let 2.9.4 be 2.0 compatible, and let 2.9.5 not be.

2.9.5 would include the changes to generic collections, etc..

Thanks,
Troy


On Mon, May 9, 2011 at 1:49 PM, Digy digyd...@gmail.com wrote:

 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 [mailto:thowar...@gmail.com]
 Sent: Monday, May 09, 2011 11: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 votes regarding the topic of .Net Framework support.

 The question on the table is:

 Should Apache Lucene.Net 2.9.4 be the last release which supports the
 .Net 2.0 Framework?

 Some options are:

 [+1] - Yes, move forward to the latest .Net Framework version, and drop
 support for 2.0 completely. New features and performance are more important
 than backwards compatibility.
 [0] - Yes, focus on the latest .Net Framework, but also include patches
 and/or preprocessor directives and conditional compilation blocks to
 include
 support for 2.0 when needed. New features, performance, and backwards
 compatibility are all equally important and it's worth the additional
 complexity and coding work to meet all of those goals.
 [-1] No, .Net Framework 2.0 should remain our target platform. Backwards
 compatibility is more important than new features and performance.


 This vote is not limited to the Apache Lucene.Net IPMC. All
 users/contributors/committers/mailing list lurkers are welcome to cast
 their
 votes with an equal weight. This has been cross posted to both the dev and
 user mailing lists.

 Thanks,
 Troy

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Nicholas Paldino [.NET/C# MVP]]

+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 votes regarding the topic of .Net Framework support.

The question on the table is:

Should Apache Lucene.Net 2.9.4 be the last release which supports the
.Net 2.0 Framework?

Some options are:

[+1] - Yes, move forward to the latest .Net Framework version, and drop
support for 2.0 completely. New features and performance are more important
than backwards compatibility.
[0] - Yes, focus on the latest .Net Framework, but also include patches
and/or preprocessor directives and conditional compilation blocks to include
support for 2.0 when needed. New features, performance, and backwards
compatibility are all equally important and it's worth the additional
complexity and coding work to meet all of those goals.
[-1] No, .Net Framework 2.0 should remain our target platform. Backwards
compatibility is more important than new features and performance.


This vote is not limited to the Apache Lucene.Net IPMC. All
users/contributors/committers/mailing list lurkers are welcome to cast their
votes with an equal weight. This has been cross posted to both the dev and
user mailing lists.

Thanks,
Troy

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Troy Howard]

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 having features/code which are different from the
Java library. 2.9.4g sounds like a bug fix version for 2.9.4.

Thanks,
Troy


On Mon, May 9, 2011 at 2:02 PM, Digy digyd...@gmail.com wrote:
 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: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache 
 Lucene.Net 2.9.4

 We could specify a new version starting with 2.9.4g and call it 2.9.5
 ... Let 2.9.4 be 2.0 compatible, and let 2.9.5 not be.

 2.9.5 would include the changes to generic collections, etc..

 Thanks,
 Troy


 On Mon, May 9, 2011 at 1:49 PM, Digy digyd...@gmail.com wrote:

 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 [mailto:thowar...@gmail.com]
 Sent: Monday, May 09, 2011 11: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 votes regarding the topic of .Net Framework support.

 The question on the table is:

 Should Apache Lucene.Net 2.9.4 be the last release which supports the
 .Net 2.0 Framework?

 Some options are:

 [+1] - Yes, move forward to the latest .Net Framework version, and drop
 support for 2.0 completely. New features and performance are more important
 than backwards compatibility.
 [0] - Yes, focus on the latest .Net Framework, but also include patches
 and/or preprocessor directives and conditional compilation blocks to
 include
 support for 2.0 when needed. New features, performance, and backwards
 compatibility are all equally important and it's worth the additional
 complexity and coding work to meet all of those goals.
 [-1] No, .Net Framework 2.0 should remain our target platform. Backwards
 compatibility is more important than new features and performance.


 This vote is not limited to the Apache Lucene.Net IPMC. All
 users/contributors/committers/mailing list lurkers are welcome to cast
 their
 votes with an equal weight. This has been cross posted to both the dev and
 user mailing lists.

 Thanks,
 Troy

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Troy Howard]

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 [mailto:thowar...@gmail.com]
 Sent: Tuesday, May 10, 2011 12:21 AM
 To: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache 
 Lucene.Net 2.9.4

 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 having features/code which are different from the
 Java library. 2.9.4g sounds like a bug fix version for 2.9.4.

 Thanks,
 Troy


 On Mon, May 9, 2011 at 2:02 PM, Digy digyd...@gmail.com wrote:
 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: lucene-net-dev@lucene.apache.org
 Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache 
 Lucene.Net 2.9.4

 We could specify a new version starting with 2.9.4g and call it 2.9.5
 ... Let 2.9.4 be 2.0 compatible, and let 2.9.5 not be.

 2.9.5 would include the changes to generic collections, etc..

 Thanks,
 Troy


 On Mon, May 9, 2011 at 1:49 PM, Digy digyd...@gmail.com wrote:

 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 [mailto:thowar...@gmail.com]
 Sent: Monday, May 09, 2011 11: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 votes regarding the topic of .Net Framework support.

 The question on the table is:

 Should Apache Lucene.Net 2.9.4 be the last release which supports the
 .Net 2.0 Framework?

 Some options are:

 [+1] - Yes, move forward to the latest .Net Framework version, and drop
 support for 2.0 completely. New features and performance are more important
 than backwards compatibility.
 [0] - Yes, focus on the latest .Net Framework, but also include patches
 and/or preprocessor directives and conditional compilation blocks to
 include
 support for 2.0 when needed. New features, performance, and backwards
 compatibility are all equally important and it's worth the additional
 complexity and coding work to meet all of those goals.
 [-1] No, .Net Framework 2.0 should remain our target platform. Backwards
 compatibility is more important than new features and performance.


 This vote is not limited to the Apache Lucene.Net IPMC. All
 users/contributors/committers/mailing list lurkers are welcome to cast
 their
 votes with an equal weight. This has been cross posted to both the dev and
 user mailing lists.

 Thanks,
 Troy

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Aaron Powell]

+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

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | 
MSN: aaz...@hotmail.com

-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com] 
Sent: Tuesday, 10 May 2011 6:05 AM
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 votes regarding the topic of .Net Framework support.

The question on the table is:

Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 
Framework?

Some options are:

[+1] - Yes, move forward to the latest .Net Framework version, and drop support 
for 2.0 completely. New features and performance are more important than 
backwards compatibility.
[0] - Yes, focus on the latest .Net Framework, but also include patches and/or 
preprocessor directives and conditional compilation blocks to include support 
for 2.0 when needed. New features, performance, and backwards compatibility are 
all equally important and it's worth the additional complexity and coding work 
to meet all of those goals.
[-1] No, .Net Framework 2.0 should remain our target platform. Backwards 
compatibility is more important than new features and performance.


This vote is not limited to the Apache Lucene.Net IPMC. All 
users/contributors/committers/mailing list lurkers are welcome to cast their 
votes with an equal weight. This has been cross posted to both the dev and user 
mailing lists.

Thanks,
Troy

Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Troy Howard]

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 .Net 4.0 framework target vs 2.0 or 3.5...

Thanks,
Troy


On Mon, May 9, 2011 at 2:40 PM, Aaron Powell m...@aaron-powell.com wrote:
 +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

 http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | 
 MSN: aaz...@hotmail.com

 -Original Message-
 From: Troy Howard [mailto:thowar...@gmail.com]
 Sent: Tuesday, 10 May 2011 6:05 AM
 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 votes regarding the topic of .Net Framework support.

 The question on the table is:

 Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 
 2.0 Framework?

 Some options are:

 [+1] - Yes, move forward to the latest .Net Framework version, and drop 
 support for 2.0 completely. New features and performance are more important 
 than backwards compatibility.
 [0] - Yes, focus on the latest .Net Framework, but also include patches 
 and/or preprocessor directives and conditional compilation blocks to include 
 support for 2.0 when needed. New features, performance, and backwards 
 compatibility are all equally important and it's worth the additional 
 complexity and coding work to meet all of those goals.
 [-1] No, .Net Framework 2.0 should remain our target platform. Backwards 
 compatibility is more important than new features and performance.


 This vote is not limited to the Apache Lucene.Net IPMC. All 
 users/contributors/committers/mailing list lurkers are welcome to cast their 
 votes with an equal weight. This has been cross posted to both the dev and 
 user mailing lists.

 Thanks,
 Troy

RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4

[Granroth, Neal V.]

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 toolset.

- Neal

-Original Message-
From: Aaron Powell [mailto:m...@aaron-powell.com] 
Sent: Monday, May 09, 2011 4:41 PM
To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org
Subject: RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache 
Lucene.Net 2.9.4

+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

http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell | 
MSN: aaz...@hotmail.com

-Original Message-
From: Troy Howard [mailto:thowar...@gmail.com] 
Sent: Tuesday, 10 May 2011 6:05 AM
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 votes regarding the topic of .Net Framework support.

The question on the table is:

Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 
Framework?

Some options are:

[+1] - Yes, move forward to the latest .Net Framework version, and drop support 
for 2.0 completely. New features and performance are more important than 
backwards compatibility.
[0] - Yes, focus on the latest .Net Framework, but also include patches and/or 
preprocessor directives and conditional compilation blocks to include support 
for 2.0 when needed. New features, performance, and backwards compatibility are 
all equally important and it's worth the additional complexity and coding work 
to meet all of those goals.
[-1] No, .Net Framework 2.0 should remain our target platform. Backwards 
compatibility is more important than new features and performance.


This vote is not limited to the Apache Lucene.Net IPMC. All 
users/contributors/committers/mailing list lurkers are welcome to cast their 
votes with an equal weight. This has been cross posted to both the dev and user 
mailing lists.

Thanks,
Troy