Shai Erera (JIRA) wrote:
[ https://issues.apache.org/jira/browse/LUCENE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699344#action_12699344 ]
Shai Erera commented on LUCENE-1593:
------------------------------------
bq. I believe if a user upgrades to release XX.9 and removes all code that is
using deprecated methods/classes, it needs to be a jar drop in for 3.0.
This might work, but 3.0 is also about moving to Java 5 with all the
implications. If my app is already on Java 5, then a jar drop is all that'll be
required. But if not, I need to update my app anyway. In addition, there are
some changes in runtime behavior that are going to be made in 3.0. My point is
- I don't know who will actually upgrade to 3.0 by just dropping a jar.
Runtime behavior changes are allowed, they just have to be described in
changes.txt.
But anyway, I'm not going to argue with policies -
The policies are what they are, but that doesn't mean they can't be
improved or discussed or changed. In the end, I think the final decision
comes down to a vote from the Lucene PMC. I'm a committer, not a PMC
member, so I don't even bear any special weight there ;)
you seem to know better than me about Lucene's back-compat requirements. So the
question is whether we want to deprecate these methods and add the new ones,
and if so, can we agree on the new names (add, updateTop)?
I think thats probably the way to go, but you can wait and see what
others say. Policies, shmalocies - it really just comes down to
consensus around here.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
