lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Swain <>
Subject Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
Date Wed, 21 Sep 2011 12:22:18 GMT
I think I'd like to stick with 2 packages Core Contrib

Just because I think it's nice and simple. I would say that any contrib
parts that get really big or popular either to split out into their own
package or  maybe added to the core package?

I'm also in favour of a nightly package and experimental packages.

Dan Swain

On Wed, Sep 21, 2011 at 4:56 AM, Michael Herndon <> wrote:

> We're taking a quick poll over the next few days to see how people would
> like use Lucene.Net through Nuget on the developers mailing list**
> Currently version 2.9.2 is hosted on, but that package was not
> create by the project maintainers, thus nuget is not currently set up in
> source.  Going forward, we would like to continue what someone else started
> by creating nuget packages for Lucene.Net.
> Right now there are two packages: Lucene & Lucene.Contrib.  My question to
> the community is do you wish to finer grain packages, i.e. a package for
> each contrib project or continue to keep it simple.
> The granular approach will let you use only what you need. We can also
> create additional higher level packages which have dependencies on the
> other
> ones.   Possibly a Lucene.Net-Essentials and Lucene.Net-Full.
> Or we can keep it simple and continue with only two packages.
> My concerns are that the granular approach might overwhelm people with
> choice. The simple choice might be considered bloat for importing and then
> installing assemblies that you might never use.
> Another topic to converse about is would you like to see an out-of-band
> project nuget feed for  nightly builds, branches with new or experimental
> features, or stable code snapshots for a projected release?
> ** when you post, please respond to
>  This
> was posted to both lists to make sure everyone subscribed to both lists has
> a chance to voice their use cases or concerns.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message