lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Busch <>
Subject Re: Proposal for changing Lucene's backwards-compatibility policy
Date Fri, 16 Oct 2009 18:43:16 GMT
On 10/16/09 10:27 AM, Steven A Rowe wrote:
> On 10/16/2009 at 2:58 AM, Michael Busch wrote:
>> B) best effort drop-in back compatibility for the next minor version
>> number only, and deprecations may be removed after one minor release
>> (e.g. v3.3 will be compat with v3.2, but not v3.4)
> This is only true on a per-feature basis.  For example, if feature A is deprecated in
v3.1, and feature B is deprecated in v3.2, then v3.3 will be "compat" with v3.2 only as far
as feature B is concerned; feature A will no longer be present in v3.3.
> Under these circumstances, saying "v3.3 will be compat with v3.2" with no caveats sounds
to me like false advertising.
> Steve

That is true. Further above in my mail I said "simple jar drop-in 
replacement will not be possible anymore with almost every Lucene 
release"and I should have made it clearer in the sentence you pointed 
out too: with option B you can only be sure that you can switch to a new 
version (e.g. v3.3) without the need to recompile if your app compiled 
against the previous version (v3.2) without deprecation warnings.

Let me point out that in any case, no matter if we pick A or B, the 
committers will try what they can to make upgrading as easy as possible. 
If you look back in Lucene's history I think we always did that, 
especially with index file format (I don't think we ever required 
reindexing to upgrade). Now in terms of API backwards-compatibility even 
with option B it doesn't mean we'll go crazy with deprecations and 
removals. We don't *have* to remove an API in 3.3 only because it was 
deprecated in 3.2.

Let me give you another example: the current TokenStream API changes 
were very big, and the TokenStream API is very central and often 
extended by users. Now with the current backwards-compatibility policy 
we decided to remove the old API entirely in 3.0. If we had policy B in 
place already, we'd be able wait until 3.1 and give users more 
transition time. But we certainly don't want to wait until 4.0 - it may 
be surprising for many how much (complicated) code is currently in 
Lucene to support compatibility for this and other features.

Even if we try to make major releases more often, how often do people 
realistically expect this will happen? Lucene 2.0 was released in May 
2006. The 2.9 release that is now available still supports every single 
public and protected API from the last 3 1/2 years. We're saying for 
about 2 years now that we should make releases more often in general. 
The committers always vote +1 if someone says "let's release more 
often". But if didn't happen so far. We could now analyze the reasons 
and how we could change that. But frankly I think partially it's just 
the nature of things: there are many different people, with different 
schedules, working on different features of different sizes and Lucene 
has different components. Getting all this aligned isn't so easy. Why 
will just saying once again "Hey, let's just release more often" work 
now if it hasn't in the last two years?


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

View raw message