lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 20:45:57 GMT

----- Original Message ----
> From: Andi Vajda <>
> To:
> Sent: Thu, March 4, 2010 2:13:22 PM
> Subject: Re: [VOTE] merge lucene/solr development
> On Thu, 4 Mar 2010, Mark Miller wrote:
> > Who knows - this isn't the official count - just a gauge of what has happened.
> > 
> > What the true votes of the *'s are remains to be seen - I wouldn't default 
> them either way as the voters seemed to think they can vote with a clause - we 
> don't know what they would vote without. But right now they vote +1 with an 
> asterisk.
> Indeed. In my case, if the hard synchronisation of releases in both directions 
> were to become a hard requirement, I would probably vote -1.

I don't think we want hard release syncing.  We have a clear unidirectional dependency.  Thus:

> I'm +1 with making it a requirement that in order to release Solr we'd have to 
> release Lucene too.

If a bug in a Solr release is found, it should get a new bugfix release (off the x.x branch),
even if there is no Lucene release.  That x.x.x release of Solr would include the same Lucene
jars as the x.x version.

> I am -1 making it a requirement that in order to release Lucene we'd have to 
> release Solr too.

I think everyone is in agreement with that.
I think we all realize that while we don't want Solr releases to trail Lucene releases a lot,
there will be some delay.  It's just that that delay could be smaller if Solr used either
Lucene trunk or if we had a process that updated Lucene jars in Solr lib/ dir in Solr svn
repo on a nightly basis (call it near-real-time trunk ;)).


> Infrequent releases have been a problem on Lucene and, apparently, an even worse 
> one on Solr. Until Solr has shown that it can release as frequently as Lucene I 
> don't think slowing down Lucene releases even more is a good move.
> I think that merging the projects as proposed would make it a easier for Solr to 
> improve its release frequency, though. This my +1 vote on the rest of the 
> proposal.
> Andi..

View raw message