lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <s...@shadstorhaug.com>
Subject RE: [Vote] Apache Lucene.Net 4.8.0-beta00003
Date Wed, 17 May 2017 19:20:47 GMT
The assembly version is the main problem - it is too high. You can always increment a version
after it is in the wild, but never decrement it. The rest of the metadata is also not present
on the 2 assemblies, but I don't consider that a blocker.

The DefaultCodecFactory is also going to be a problem - in many environments the codecs won't
be able to initialize and the application will crash because the initialization takes place
too early in the application's lifecycle.


-----Original Message-----
From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar
Syn-Hershko
Sent: Thursday, May 18, 2017 1:49 AM
To: dev@lucenenet.apache.org
Subject: Re: [Vote] Apache Lucene.Net 4.8.0-beta00003

Why is this a blocker?

--

Itamar Syn-Hershko
Freelance Developer & Consultant
Elasticsearch Partner
Microsoft MVP | Lucene.NET PMC
http://code972.com | @synhershko <https://twitter.com/synhershko> http://BigDataBoutique.co.il/

On Wed, May 17, 2017 at 8:59 PM, Shad Storhaug <shad@shadstorhaug.com>
wrote:

> -1
>
> Found a couple of showstoppers.
>
> First of all, when working in BoboBrowse.Net, I noticed when an object 
> browser window opened up that QueryParser was listed twice. The reason 
> is because the .NET Framework and .NET Core assemblies have different 
> versions. The assembly version number is wrong on the .NET Core 
> assembly. I checked the other assemblies and the version number is 
> also wrong on the Expressions .NET Core assembly, but the rest are 
> fine. The configuration to set these numbers is correct - there is 
> absolutely no reason why the assembly number shouldn't be right - 
> except that the .NET core project.json-based tools are unreliable. I 
> have been able to work around issues like this before by duplicating 
> the configuration for each framework and I am sure that will fix this, 
> but I am at a loss to explain why the exact same configuration fails on some projects
but not others.
>
> Secondly, the bug that Mattias reported led me to find a problem that 
> is pretty serious. The initialization for the DefaultCodecFactory 
> needs to be changed to be lazy loaded instead of executed in the 
> constructor. The codec initialization will likely fail in many ASP.NET 
> applications where certain operations are not allowed during 
> construction. I also noticed a couple of places in the 
> DefaultCodecFactory that could use some concurrency locking.
>
> Thanks,
> Shad Storhaug (NightOwl888)
>
> -----Original Message-----
> From: Shad Storhaug [mailto:shad@shadstorhaug.com]
> Sent: Wednesday, May 17, 2017 1:02 AM
> To: dev@lucenenet.apache.org
> Subject: [Vote] Apache Lucene.Net 4.8.0-beta00003
>
> Third time's a charm. We've fixed the index corruption issue (that 
> turns out *only* happens when using x86 in combination with binary doc 
> values) which means indexes written under those conditions with prior 
> versions may not be able to be read by this version (breaking change).
>
> There were also a few other bugs fixed and for the first time ever 
> there were no test failures on .NET Framework. The only tests that 
> failed on .NET Core were 2 that have been manually set to fail (since 
> .NET Core cannot catch AccessViolationExceptions). We can't say for 
> sure that the flakey tests are all fixed, but this is a good sign.
>
>
>
> The source and binary packages are available for inspection at:
> https://dist.apache.org/repos/dist/dev/lucenenet/.
>
>
>
> There is a MyGet feed that can be accessed at:
>
>
>
> V2: https://www.myget.org/F/lucene-net-nuget/api/v2 (VS2012+)
>
> V3: https://www.myget.org/F/lucene-net-nuget/api/v3/index.json 
> (VS2015+)
>
>
>
> The tag is: https://github.com/apache/lucenenet/releases/tag/Lucene.
> Net_4_8_0_beta00003
>
>
>
>
>
> Please review the beta and vote (build and test instructions now on 
> the README).
>
>
>
> This vote will close no sooner than 72 hours from now, i.e. sometime 
> after
> 18:00 UTC 20-May 2017
>
>
>
>
>
> +1 - Yes
>
> 0 - Indifferent
>
> -1 - Not ready, because...
>
> Thanks,
> Shad Storhaug (NightOwl888)
>
Mime
View raw message