lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <reng...@ix.netcom.com>
Subject Re: Back Compatibility
Date Fri, 18 Jan 2008 00:57:30 GMT
If they are " no longer actively developing the portion of the code  
that's broken, aren't seeking the new feature, etc", and they stay  
back on old versions... isn't that exactly what we want? They can  
stay on the old version, and new application development uses the  
newer version.

It would be different if it was a core JRE interface or similar -  
this is an optional jar.

Part of what always made Windows so fragile is that as it evolved  
they tried to maintain backward compatibility - making working with  
the old/new code and fixing bugs almost impossible. The bloat became  
impossible to deal with.

I bet, if you did a poll of all Lucene users, you would find a  
majority of them still only run 1.4.3, or maybe 1.9. Even with 2.0,  
2.3, or 3.0, that is still going to be the case.

As always, JMO.

On Jan 17, 2008, at 3:14 PM, Doug Cutting wrote:

> Grant Ingersoll wrote:
>> 1. We add a new section to CHANGES for each release, at the top  
>> where we can declare what deprecations will be removed in the  
>> _next_ release (major or minor)  and also any interface API changes
>> 2. When deprecating, the @deprecate tag should declare what  
>> version it will be removed in and that version must be one greater  
>> than the next targeted release.  That is, if the next release is  
>> 2.4, then anything deprecated in 2.3 is game to be removed in 2.9.
>
> This would mean that one could never simply drop in the new jar and  
> expect things to still work, which is something that we currently  
> try to guarantee.  That's a significant thing to give up, in terms  
> of usability.  In my experience, folks hate incompatible changes,  
> since they're frequently no longer actively developing the portion  
> of the code that's broken, aren't seeking the new feature, etc.   
> This is why lots of folks stay back on old versions.
>
> In terms of benefits, this would permit us to evolve APIs more  
> rapidly.  So it pits external usability against API evolution  
> speed, with no clear winner.  +0
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


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


Mime
View raw message