The granular approach can cause dependency issues as well. FubuMVC is running into this with their granularity had to invent their own build chain for "ripples" of changes.
I would say do two packages Lucene and Contrib and when one of the pieces of Contrib gets awesome enough to warrant it's own package. I look forward to official Lucene.Net packages. On Tue, Sep 20, 2011 at 10:56 PM, Michael Herndon < mhern...@wickedsoftware.net> 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 nuget.org, 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 lucene-net-...@lucene.apache.org. > This > was posted to both lists to make sure everyone subscribed to both lists has > a chance to voice their use cases or concerns. >
