lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Subversion conversion
Date Thu, 03 Feb 2005 12:06:17 GMT
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.


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 <>
> Runtime Collective Ltd.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message