----- Original Message ---- > From: Bill Au <bill.w...@gmail.com> > To: general@lucene.apache.org > Sent: Wed, March 3, 2010 11:29:33 PM > Subject: Re: [VOTE] merge lucene/solr development > > In the case where changes are in Lucene only I think it is OK to increment > the Solr release number since even though the Solr jars are unchanged > because the new release of Solr will contain the new Lucene jars. But what > about the case where changes are in Solr only? Would we still increment the > Lucene release number even though everything in the Lucene download is the > same as before?
I don't think Lucene version would change in this case. Why do/should release numbers have to remain in sync? I missed that part... Otis > On Wed, Mar 3, 2010 at 10:13 PM, Michael Busch wrote: > > > On 3/3/10 6:00 PM, Yonik Seeley wrote: > > > >> On Wed, Mar 3, 2010 at 8:10 PM, Michael Busch wrote: > >> > >> > >>> So if it seems like that most people are concerned about releases (even > >>> > >>> those you are generally in favor of this proposal), then maybe we should > >>> discuss exactly this point. We haven't really discussed alternatives > >>> about > >>> the release alignment. This vote feels rushed. > >>> > >>> > >> It's been discussed for a week, and I'm with Mark - I'm only for a > >> real merge of development, and that includes release schedules. > >> > >> -Yonik > >> > >> > >> > > > > How will we merge release policies? (or are they exactly the same?) Does > > Solr use the same release numbering? Does it have the same > > backwards-compatibility requirements as Lucene? > > > > If we release Solr 1.5.0 with Lucene 3.1.0, and we find a bug in the Lucene > > jar and want to release a 3.1.1 bugfix release, will we also release a Solr > > 1.5.1, even though all Solr jars would be identical to the 1.5.0? > > Or will we just release Solr/Lucene 4.0.0 next and always use same release > > numbers? > > > > How will we avoid longer release cycles? Solr had had very infrequent > > releases. What were the reasons for that? Are we comfortable with saying > > we'll just try to be disciplined enough or is there a way to somehow enforce > > release frequency? It seems certain that if more people work on the code, > > there will at any given point be more patches/new features under development > > and things need to be coordinated in a way that allows frequent releases. > > > > In an earlier mail I gave the following example: If we had a separate > > analyzer module, and we add an analyzer in a new language to it, it would be > > cool to release it soon, without having to wait until Lucene/Solr are ready > > for a release. The pace here can be faster, because I imagine in such an > > Analyzer module it's much less common that a patch "touches everything". > > What do people think about this? Maybe it's just a nice wish, but not > > realizable, because there'd be a lot of version management overhead. But > > maybe not? > > > > I'm not against this whole thing and I'm not trying to be difficult here, > > and I dislike endless discussions just as everyone else. But I honestly > > don't know right now how to vote, because I have those open questions and > > know that a lot of other people here are concerned about the release > > alignment as well. > > > > Michael > > > >
