RE: [Lucene.Net] 2.9.4 release couldn't be compiled for .Net3.5
>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 ThreadLocal t = new ThreadLocal(); > > 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] Stackoverflow on Lucene.net
Just received a comment on my blog post from a dev from StackOverflow. http://codeclimber.net.nz/archive/2011/12/02/Lucene-net-2-9-4-is-out-now-with-NuGet.aspx#3591 He is thanking the team for the release, and says he will update Stackoverflow to Lucene 2.9.4 soon. I guess that makes it the biggest site (and network) running on Lucene.net so far. Probably worth mentioning stackoverflow among the list of sites that use it (right sidebar in the homepage) Simone -- 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] 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 ThreadLocal t = new ThreadLocal(); > > 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] 2.9.4 release couldn't be compiled for .Net3.5
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 ThreadLocal t = new ThreadLocal(); 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] Nuget Gallery updates and how this affect Lucene.net
Hi guys, as you might, or might not, have read, the new nuget gallery is out. http://haacked.com/archive/2011/12/05/nuget_org_update.aspx Changes that affect our pkgs are two: Package owners are displayed more prominently. In the old gallery, the > owners of the package weren’t displayed. Anywhere. Which was a terrible > experience because the owners are the people who matter. A package owner is > associated with an account. The “author” of a package is simply metadata > and could be anyone. Now our pkg page (http://nuget.org/packages/Lucene.net) shows me, Prescott and the prev owner of the pkg id as owners. And the lucene.net community as owner. But in the list ( http://nuget.org/packages?q=lucene&sortOrder=package-download-count) you get only the owner names. So, maybe, it would be good to create a team-wide nuget account to add together with other accounts (like also MS is doing with it's own packages) And I would also remove the prev owner from the list, if everyone is ok with that. Package unlisting. Packages can now be unlisted. This effectively hides the > package, but the package is still used to resolve dependencies. That relates to the deprecated pkgs. We could hide the deprecated packages, so they don't show up in the gallery when ppl search for lucene. But they will still be used to resolve dependencies from other packages. But, the downside is that ppl that directly downloaded the "old" lucene pkg will not receive any update. How do we want to handle that? We keep it like we did, or do we mark it as "unlisted"? 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"
