Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Users List" <lucene-user@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <1107423200.8535.8.camel@goose.milesbarr.com>
References: 
 <BE93D3B28027E84197C08BF463AA9CD604515E05@MSGMROCLD2WIN.DMN1.FMR.COM>
 <8b6ad07a05020216494153cdfb@mail.gmail.com>
 <556c84ee503264e675cec7d73ecc9df2@ehatchersolutions.com>
 <1107423200.8535.8.camel@goose.milesbarr.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <434ddcabbebd5eec3bd3759369d3369f@ehatchersolutions.com>
Content-Transfer-Encoding: 7bit
From: Erik Hatcher <erik@ehatchersolutions.com>
Subject: Re: Subversion conversion
Date: Thu, 3 Feb 2005 07:06:17 -0500
To: "Lucene Users List" <lucene-user@jakarta.apache.org>

We can work the 1.x and 2.0 lines of code however we need to.  We can 
branch (a branch or tag in Subversion is inexpensive and a constant 
time operation).  How we want to manage both versions of Lucene is open 
for discussion.  Nothing about Subversion changes how we manage this 
from how we'd do it with CVS.

Currently the 1.x and 2.x lines of code are one and the same.  Once 
they diverge in 2.0, it will depend on who steps up to maintain 1.x but 
I suspect there will be a strong interest in keeping it alive by some, 
but we would of course encourage everyone using 1.x upgrade to 1.9 and 
remove deprecation warnings.

	Erik


On Feb 3, 2005, at 4:33 AM, Miles Barr wrote:

> On Wed, 2005-02-02 at 22:11 -0500, Erik Hatcher wrote:
>> I've seen both of these types of procedures followed on Apache
>> projects.  It really just depends.  Lucene's codebase is not being
>> modified frequently, so it is not necessary to branch and merge back.
>> Rather we simply develop off of the trunk (HEAD) and when we're ready
>> for a release we'll just do it from the trunk.  Actually  we'd most
>> likely tag and build from that tag just to be clean about it.
>
> What consequences does this have for the 1.9/2.0 releases? i.e. after
> 2.0 the deprecated API will be removed, does this mean 1.x will no
> longer be supported after 2.0?
>
> The typical scenario being a bug is found that affects 1.x and 2.x, 
> it's
> patched in 2.x (i.e. the trunk) but we can't patch the last 1.x 
> release.
> The other scenario being a bug is found in the 1.x code, but it cannot
> be applied.
>
>
> -- 
> Miles Barr <miles@runtime-collective.com>
> Runtime Collective Ltd.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org