lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Proposal for changing Lucene's backwards-compatibility policy
Date Fri, 16 Oct 2009 17:32:06 GMT
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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>   
Right - confusing. And even if we peg deprecation removal to only given
point releases to address this, its still confusing as to which.
Solution? Major numbers :) If deprecations need to be removed faster,
instead of 4 or 5 releases within a major number, 2 or 3 could be done.

Its also a real pain for someone to skip a few releases and then upgrade
- right now you just hit the 2.9 release and get all the dep warnings to
help you go to 3.0. With this, if your late to the party, you will lose
all the dep warnings - you will have to update to every other release to
catch up.

-- 
- Mark

http://www.lucidimagination.com




---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message