2.3.2 seems like the right choice to me. Sean Carpenter On Fri, Nov 21, 2008 at 2:16 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I think it is good idea. > > Andrei > > Doug Sale ?????: > > 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.mbox/[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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> >> > >
