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 <geobmx...@hotmail.com> wrote: > > Artifacts are located here: > http://people.apache.org/~pnasser/Lucene.Net/2.9.4-incubating-RC1/ > > > 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
