lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <>
Subject Re: Lucene's default settings & back compatibility
Date Fri, 22 May 2009 19:54:28 GMT
Earwin Burrfoot wrote:
>>  4. [Maybe?] Allow certain limited changes that will require source
>>     code changes in your app on upgrading to a new minor release:
>>     adding a new method to an interface, adding a new abstract method
>>     to an abstract class, renaming of deprecated methods.
> Yahoo! The right to rename deprecated things makes the need to
> deprecate VS simply remove bearable.

I've also noticed the ugly name problem. I would be in favor of a 
cleanup of ugly names.

Using the existing policy mechanism, one could (I haven't thought this 

In 3.0, remove the deprecations.

Do a 3.9 release with:
a) add methods and classes with the good names. These should be an exact 
copy of the ugly named code.
b) deprecate the ugly names.
c) no other changes.

Release 4.0 with deprecations removed.

These three releases could happen simultaneously.

(Of course, if we want to do this, we could have a policy that we have a 
2.9.0 and an 2.9.1 (rather than 3.9) followed by a 3.0 with good names.)

Now we are back to good names. And drifting can start all over again.

-- DM

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

View raw message