I got lastest - so hopefully not :)
I think I'd cry a little bit if it got wiped. ---------------------------------------- > Date: Sat, 19 Nov 2011 17:55:05 -0800 > From: currens.ch...@gmail.com > To: lucene-net-dev@lucene.apache.org > Subject: RE: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating > > I build it using trunk/build/scripts/build.cmd all all - in the scripts > folder. Make sure you've updated the folder. That message is suspiciously > close to the message that would appear when it had the bug that would wipe > entire drives. > On Nov 19, 2011 4:25 PM, "Prescott Nasser" <geobmx...@hotmail.com> wrote: > > > > > Hey Michael, I'm running build and getting the following error: > > > > > > > > > > build\scripts> ./build > > > > ... > > The target 'all' does not exist in the project > > > > ... > > > > > > > > > > > > Should I be passing a command line argument to build all? > > > > > > > > > > > > > > ---------------------------------------- > > > Date: Mon, 31 Oct 2011 16:39:30 -0400 > > > From: mhern...@wickedsoftware.net > > > To: lucene-net-dev@lucene.apache.org > > > Subject: Re: [Lucene.Net] [VOTE] Apache Lucene.Net-2.9.4-incubating > > > > > > @Troy, > > > > > > 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 > > > binaries. > > > > > > -.snk > > > 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 <thowar...@gmail.com> > > 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 < > > 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 > > > >
