lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Carpenter" <stcarpen...@gmail.com>
Subject Re: Lucene.Net 2.3.1 Candidate
Date Fri, 21 Nov 2008 12:10:30 GMT
2.3.2 seems like the right choice to me.
Sean Carpenter

On Fri, Nov 21, 2008 at 2:16 AM, xzxz@mail.ru <xzxz@mail.ru> 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/%3C8e3fbf150810161402tb68e1edyabf6e669484e3902@mail.gmail.com%3E
>>
>> Please comment.
>>
>> Thanks,
>> Doug
>>
>> On Tue, Nov 18, 2008 at 8:01 PM, George Aroush <george@aroush.net> 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:dougsale@gmail.com]
>>>> 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 <digydigy@gmail.com> 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:george@aroush.net]
>>>>> 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:digydigy@gmail.com]
>>>>>> 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:dougsale@gmail.com]
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message