lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Au <>
Subject Re: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 04:29:33 GMT
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?


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message