lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Sale" <dougs...@gmail.com>
Subject Re: Lucene.Net 2.3.1 Candidate
Date Thu, 20 Nov 2008 22:17:31 GMT
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