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
through):
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
