lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Aroush" <geo...@aroush.net>
Subject RE: Lucene.Net 2.3.1 Candidate
Date Wed, 19 Nov 2008 02:25:04 GMT
Hi Ron,

I would not suggest it, for those reasons:

1) Since 2.3.1 isn't RC yet, if you do find an issue with it, chances are
it's also in 2.3.2 so you have to fix it in two places.  This maybe get a
bit tricky if the change in 2.3.2 is in a newly ported area of code.

2) Since 2.3.1 isn't RC yet, If you have an issue in 2.3.2, you will not
know for sure if it's port issue or a real issue carried over from 2.3.1.

3) Jumping to 2.3.2 without RC'ing 2.3.1, discourages additional work on
2.3.1 and thus jeopardizes it from reaching RC and then officially releasing
it.

Keep in mind, the whole point of incubation is to learn the Apache way so
the project can graduate -- in my opinion, it's important to formally
release 2.3.1 which I don't think is that far off.

Regards,

-- George


> -----Original Message-----
> From: Ron Grabowski [mailto:rongrabowski@yahoo.com] 
> Sent: Tuesday, November 18, 2008 9:09 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: Lucene.Net 2.3.1 Candidate
> 
> Can't you start the 2.3.2 stuff in a branch them copy it into 
> trunk once 2.3.1 ships?
> 
> 
> 
> ----- Original Message ----
> From: George Aroush <george@aroush.net>
> To: lucene-net-dev@incubator.apache.org
> Sent: Tuesday, November 18, 2008 9:01:56 PM
> Subject: RE: Lucene.Net 2.3.1 Candidate
> 
> 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
View raw message