lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <>
Subject Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
Date Wed, 21 Sep 2011 21:15:07 GMT
Use a Lucene.Net core package for the core, and separate packages for each
contrib. That makes the most sense, and that is how most projects work. This
is also how Java Lucene does.

Don't create a nightly nuget package - nuget should only be used for
distribution packages

On Wed, Sep 21, 2011 at 6: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