lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Herndon <>
Subject Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
Date Mon, 31 Oct 2011 20:39:30 GMT

Now I don't feel as bad for my long e-mails. ;)

-build scripts

Except for building on mono or running NCover, the scripts work as
intended. Also end users would need to install the required tools they
intend to run with the build scripts. The scripts can be included, but it
would be wise to include those caveats in a read-me somewhere.

And there are ways to override the build scripts for user/custom build
configurations.  For those interested, post questions on a new thread.

When you run the build scripts they should be including the xml files in
the trunk/bin folder on successful builds. Please do let me know if that
was not the case on your local machine if you used the scripts to build the

The .snk in the lib folder is the original.  When you create a new csproj,
that is the file you use sign the binary with a strong key. The project
defaults to creating a copy of the .snk file in its own folder.  I can't
remember if there is a way to just link it to only one file or not, but
that was the default behavior.

So to answer your question, if users/developers to create their own contrib
projects or their own ci based upon a stable release tag and plan to use
the same .snk, then it would be wise to include all of lib.  If they are
just building from a stable branch, you can exclude the .snk file as each
project that uses it will have its own copy.

- docs
Generating both chm/html at the moment.  I'll push the html version into
source tonight for the website. and push a zip file with both the chm &
static html site into a jira ticket.  The chm is handy when you're in
facility that is locked down and need to move around good deal of help
files on a thumb drive.

The xml files should be included. The xml files are only generated when you
currently build a binary in Release mode for trunk & 2.9.4g branch. So if
you build the binaries and the xml files are not there, that is the most
likely cause.

Unless someone picks up the task of improving the overall xml doc comments
between versions and generating them, most likely the documents will only
be updated between releases.

- Michael

On Mon, Oct 31, 2011 at 3:41 PM, Troy Howard <> wrote:

> Prescott,
> Good job figuring out the signing and creating the release packages!
> It's non-trivial to figure out the first time from the docs, for sure.
> Sorry, I have been so busy this month that I wasn't able to provide
> help before you figured it out on your own. :)
> Some nitpicky details about the release packages:
> - Superfluous subfolders: There's an extra layer of subfolders named
> the same as the zip file which is unneeded
> - Root should be "trunk" all the time, even in the release packages,
> to keep relative pathing consistently rooted. So the binary release
> should have a "bin" subfolder at it's root to match the repo layout
> - XML doc files should be included in binary release. We have had
> users state a desire to have them for VS intellisense integration.
> This was an issue that came up during the last release package build
> cycle
> - Various notice files should be included in binary release as well
> - I don't know about the.SNK file from lib, maybe that should be in
> the source package, maybe not. I notice it's also in the core project
> folder. Which one does the project file reference?
> - .svn folder/files should be removed from source package
> - Empty subfolders should be left out (\build\vs2008 and \test\demo
> are the ones I noticed)
> - \docs are missing from source package as well
> Regarding docs, generally speaking, I think we should make a decision
> about what we want to provide and set a standard.
> Some considerations are:
> - XML doc files in binary package: Integrate with Visual Studio,
> providing a rich Intellisense experience, Generated at build time from
> source code. Where should they go in the folder structure to make it
> "just work" with VS from binary package?
> - Hosted HTML "Single Version of the Truth" vs HTML/CHM doc files in
> binary/source package: One one hand, we could only host docs on the
> website vs distributing them. We can update as needed, and they are
> the only reference. Can host docs for multiple versions, etc..
> HTML/CHM in packages, are good for offline use, but can't be updated.
> Both can be generated from XML files using Sandcastle. We could do
> either one, or both of those.
> Using sandcastle, we can include the Apache license in the headers of
> all generated files, solving a lot of the RAT complaints.
> Also, there's a lot of new material in the repo for CI related
> things.. Do we want to include any of the in the source package, to
> assist our users with setting up their own CI servers? How simple
> would it be to modify those files to work in a different environment
> (assuming they are also using Hudkins)?
> So all that said, I think there's more work to be done and I'm -1 for
> these artifacts.
> Thanks,
> Troy
> On Sun, Oct 30, 2011 at 10:08 PM, Prescott Nasser <>
> wrote:
> >
> > Artifacts are located here:
> >
> >
> > If the vote passes here, I will move the artifacts to staging and call a
> vote on the general incubator mailing list
> >
> >
> >
> > Please verify the release and cast your vote.  The vote will be open for
> 72 hours.
> >
> > [ ] +1
> > [ ]  0
> > [ ] -1
> >
> >
> >
> >
> >
> > ~Prescott

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