lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <>
Subject Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating
Date Mon, 31 Oct 2011 19:41:19 GMT

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
- 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.


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

View raw message