+1 -Marko
On Sat, Nov 22, 2008 at 2:31 PM, Digy <[EMAIL PROTECTED]> wrote: > +1 > > DIGY > > -----Original Message----- > From: Doug Sale [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2008 12:18 AM > To: lucene-net-dev@incubator.apache.org > Subject: Re: Lucene.Net 2.3.1 Candidate > > I would like to suggest that we make the next release candidate 2.3.2 (not > 2.3.1). I have made all patches for this code available on the list and > they satisfy all the unit tests. Additionally, the Lucene 2.3.2 release is > only a bug-fix release, not a feature release (see > http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_3_2/CHANGES.txt). > > Since there exists a gap in the releases of Lucene.Net (as compared to those > of Lucene), continuity is no reason to release a 2.3.1 version. In fact, > separate releases of 2.3.1 and 2.3.2 will result in more work, when users > will only want the 2.3.2 release. > > Here is a link to my orignal post with the 2.3.2 patch: > http://mail-archives.apache.org/mod_mbox/incubator-lucene-net-dev/200810.mbo > x/[EMAIL PROTECTED] > > Please comment. > > Thanks, > Doug > > On Tue, Nov 18, 2008 at 8:01 PM, George Aroush <[EMAIL PROTECTED]> wrote: > >> Hi Doug, >> >> I strongly suggest that 2.3.1 be stabilized first and be formally release >> (or at least be prompted to RC (release candidate) status) before you > bring >> in 2.3.2 code base. Since Lucene.Net is still in incubation, there is a >> formal process to make a release -- search the Lucene.Net mailing list or >> ASF website to find out more. Making a release is an important part and a >> required process toward a graduation from incubation; it's important that >> you and DIGY experience a formal release process. >> >> Once 2.3.1 is in at least RC status, and the community has tested it >> without >> issues, then what need to happen is a copy of 2.3.1 code is made from the >> "trunc" to "tags" repository (i.e.: "svn copy".) Once this happens, then >> the "trunc" becomes 2.3.2. >> >> So, in a nutshell, before you can check-in your 2.3.2 work, it's important >> to get the current version into RC status. For this to happen, the points >> I >> highlighted to DIGY must be meet. >> >> Regards, >> >> -- George >> >> >> > -----Original Message----- >> > From: Doug Sale [mailto:[EMAIL PROTECTED] >> > Sent: Tuesday, November 18, 2008 11:56 AM >> > To: lucene-net-dev@incubator.apache.org >> > Subject: Re: Lucene.Net 2.3.1 Candidate >> > >> > I would like to put together the 2.3.1 release candidate >> > ASAP, as I'm currently sitting on the code that is the 2.3.2 >> > port. From a repository perspective, what is the protocol >> > for tagging releases? >> > >> > (Also, thanks to DIGY for executing the tedious process of >> > committing the >> > 2.3.1 patches and closing out the JIRA issues.) >> > >> > -Doug >> > >> > On Mon, Nov 17, 2008 at 10:20 AM, Digy <[EMAIL PROTECTED]> wrote: >> > >> > > I didn't know "release candidate" has so formal meaning. >> > Let's name it >> > > "mature version" for now. >> > > >> > > DIGY. >> > > >> > > -----Original Message----- >> > > From: George Aroush [mailto:[EMAIL PROTECTED] >> > > Sent: Monday, November 17, 2008 4:18 AM >> > > To: lucene-net-dev@incubator.apache.org >> > > Subject: RE: Lucene.Net 2.3.1 Candidate >> > > >> > > Hi DIGY, >> > > >> > > Few more things are needed before the SVN trunk can be promoted to >> > > release candidate, those are: >> > > >> > > 1) All AssemblyInfo.cs in /trunck/C#/src/ should have the same >> > > assembly version. >> > > 2) /trunck/C#/src/HISTORY.txt file need to reflect what has been >> > > fixed, show the build version and that this is a RC (release >> > > candidate) (change it to "final" when it becomes a release) >> > > >> > > After those changes, the community should start using the code off >> > > this trunk and if there is no issue for, lets say a month, >> > a vote for >> > > release should be called. >> > > >> > > One of the tests that I have always done before I nominate >> > a build for >> > > RC is verify that the index works with Java Lucene; you should take >> > > the time and do some basic test on this area too. Have the >> > same index >> > > be modified by Java Lucene and then by Lucene.Net. >> > > >> > > Regards, >> > > >> > > -- George >> > > >> > > >> > > > -----Original Message----- >> > > > From: Digy [mailto:[EMAIL PROTECTED] >> > > > Sent: Sunday, November 16, 2008 10:03 AM >> > > > To: lucene-net-dev@incubator.apache.org >> > > > Subject: RE: Lucene.Net 2.3.1 Candidate >> > > > >> > > > Hi All, >> > > > >> > > > >> > > > >> > > > All waiting patches to make Nunit tests pass >> > > > (+LUCENENET-159) are applied. >> > > > >> > > > Release candidate for Lucene.Net.2.3.1 is in svn trunk now. >> > > > >> > > > >> > > > >> > > > DIGY >> > > > >> > > > >> > > > >> > > > From: Doug Sale [mailto:[EMAIL PROTECTED] >> > > > Sent: Thursday, October 09, 2008 12:08 AM >> > > > To: lucene-net-dev@incubator.apache.org >> > > > Subject: Lucene.Net 2.3.1 Candidate >> > > > >> > > > >> > > > >> > > > I believe we have a candidate for the Lucene.Net 2.3.1 >> > release. It >> > > > diverges from the SVN HEAD by the list of patches below. >> > > > >> > > > LUCENENET-135 SupportClass.patch >> > > > LUCENENET-143 TestStressIndexing2.patch, FieldsReader.patch >> > > > LUCENENET-145 DocumentsWriter.patch >> > > > LUCENENET-146 SegmentTermPositionVector. >> > > > >> > > > patch >> > > > LUCENENET-151 MultiPhraseQuery.patch >> > > > >> > > > LUCENENET-152 SegmentInfos.patch, FSDirectory.patch >> > > > >> > > > LUCENENET-154 TestIndexWriterLockRelease.patch >> > > > LUCENENET-155 SetUp.patch >> > > > LUCENENET-157 GetFieldNames.patch >> > > > LUCENENET-158 CheckHits.patch >> > > > >> > > > I have attached a comprehensive patch to simplify things >> > for those >> > > > of you who would like to try it out. >> > > > >> > > > 1) Get the latest from SVN HEAD (currently revision 702987) >> > > > 2) Apply Comprehensive.patch from the root directory. >> > > > >> > > > - Doug >> > > > >> > > > >> > > >> > > >> > >> >> > >
