----- Original Message ---- > From: Andi Vajda <va...@apache.org> > To: general@lucene.apache.org > 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 ;)). Otis > 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..
