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: [email protected] [mailto:[email protected]] On Behalf Of Itamar Syn-Hershko Sent: Thursday, May 18, 2017 1:49 AM To: [email protected] 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 <[email protected]> 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:[email protected]] > Sent: Wednesday, May 17, 2017 1:02 AM > To: [email protected] > 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) >
