No, the URL in DIGY's email apepars correct and the SVN revision appears to be 1086410.
Question: Should there be a tag for Lucene.Net_2_9_4 as there are for previous release candidates? - Neal -----Original Message----- From: Wyatt Barnett [mailto:wyatt.barn...@gmail.com] Sent: Tuesday, April 05, 2011 12:15 PM To: lucene-net-dev@lucene.apache.org Cc: digy digy Subject: Re: [Lucene.Net] release 2.9.4 Thanks. For anyone watching, the corrected clickable link is https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C%23/. Also, just to make sure we are looking at this right, the revision we should be using is 1089138 -- main thing is I've been in and out of town, not caught up on anything and I'd hate to start building stuff against the wrong version . . On Tue, Apr 5, 2011 at 1:10 PM, digy digy <digyd...@gmail.com> wrote: > Sorry, no binaries. You can download the source from > https://svn.apache.org/repos/asf/incubator/lucene.net/trunk/C#/src/Lucene.Net > > DIGY > > On Tue, Apr 5, 2011 at 12:12 AM, Wyatt Barnett <wyatt.barn...@gmail.com>wrote: > >> Actually about to dive into a big search tweaking spike in a certain >> project here, happy to do it on 2.9.4. Got binaries? >> >> On Mon, Apr 4, 2011 at 12:27 PM, Troy Howard <thowar...@gmail.com> wrote: >> > We don't have any sort of QA report on the latest build. DIGY called >> > for testing, but I haven't seen anyone respond to that request >> > indicating successful testing. >> > >> > So, how do we want to manage this? >> > >> > In the business world, we'd never think of making a release without >> > extensive QA first. In my other open source projects, either we've >> > managed QA ourselves by 'switching hats' for a couple weeks prior to >> > release, or just crossed our fingers because the user base was too >> > small. >> > >> > Lucene.Net is a fairly high-profile project, with a large user base. I >> > think it would not be responsible to make a release without a formal >> > QA process. We do have extensive unit tests, but do you think those >> > are sufficient to cover our QA needs? Should we try to find community >> > members with a specialty in software testing that would be willing to >> > fulfill this role on our project? Should we just swap hats? >> > >> > I didn't worry about this issue with the latest 2.9.2 release because >> > it was QAed by the user base for a long time before it was an >> > 'official release'. Maybe this is an effective tactic? Release first, >> > and let the user base roll in bug reports fixing them on yet later >> > minor maintenance releases? This seems to be the method a lot of >> > projects use (i.e. no specific QA process, but rather an organic >> > process of 'try our best then deal with bug reports later'). >> > >> > What do we think about this? >> > >> > Thanks, >> > Troy >> > >> > >> > On Sun, Apr 3, 2011 at 11:59 PM, Prescott Nasser <geobmx...@hotmail.com> >> wrote: >> >> >> >> Hey all, >> >> >> >> I know we have a number of outstanding JIRA issues, but I think most of >> them have been handled for the 2.9.4 release? Do we have anything >> outstanding that is holding back a new release? >> >> >> >> ~P >> > >> >
