RE: ICU4NET 64bit?

Hi, I apologise for the delayed response. In the .NET Core migration I am working on, with the current .NET Core toolchain, it compiles for x64 even if a 32-bit runtime is specified. :( (It’s a known

Re: nuget.org and 4.8

>> Thanks for all the hard work getting the code ready enough to have this discussion. Indeed! happy times! I say we keep the nightly builds published on myget. We can promote packages from myget to nuget with a click of a button. We can do this now to have the latest bits out there on myget as

Re: ICU4NET 64bit?

Ok, let's see what ICU support Shad and Connie come up with. Worst case we can release all analyzers requiring the ICU packages as a separate package and remove the ICU dependency from the more commonly used parts. -- Itamar Syn-Hershko http://code972.com | @synhershko

[GitHub] lucenenet issue #191: [WIP] Migrating Lucene.Net to .NET Core

Github user synhershko commented on the issue: https://github.com/apache/lucenenet/pull/191 Thanks for the clarifications. Probably make sense to have it documented in code itself then :) --- If your project is set up for it, you can reply to this email and have your reply appear on

[GitHub] lucenenet issue #193: Completed Grouping Implementation

Github user NightOwl888 commented on the issue: https://github.com/apache/lucenenet/pull/193 Oops, looks like the first attempt to push was rejected and I posted the wrong commit before. The new test class override rollback point is:

[GitHub] lucenenet issue #193: Completed Grouping Implementation

Github user NightOwl888 commented on the issue: https://github.com/apache/lucenenet/pull/193 I have now merged these changes to master. Do note that there is a new commit where the test class override stubs can be reverted (if needed):

[GitHub] lucenenet issue #191: [WIP] Migrating Lucene.Net to .NET Core

Github user NightOwl888 commented on the issue: https://github.com/apache/lucenenet/pull/191 > >There are 2 different PriorityQueue types in Lucene.Net > Is there a reason for this? Can we stay with one? Yes, there is a reason for that – that is the way it is

RE: Compilation issues and gotchas

Itamar, I think we should seriously take this into consideration: https://blogs.msdn.microsoft.com/dotnet/2015/12/09/support-ending-for-the-net-framework-4-4-5-and-4-5-1/. If Microsoft isn't supporting 4.0, 4.5, or 4.5.1 we probably shouldn't either (although it wouldn't be a bad thing to