[
https://issues.apache.org/jira/browse/SOLR-14469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113131#comment-17113131
]
Erick Erickson commented on SOLR-14469:
---------------------------------------
One idea that has come up is to deal with the problem of accumulating cruft via
precommit rather than fail compilations. So one idea is to fail precommit
(again, master only and gradle) if:
1. the deprecation annotation doesn't have a "remove in..." message, exact form
TBD
2. the deprecation annotation doesn't have an indication of what to do instead
(use method ###, delete, ...), exact form TBD
3. Given <1>, fail if the Lucene/Solr version that's being checked is >= the
version mentioned in the annotation.
That would make cutting the next major version more painful, all the
deprecations to be removed in that major version would have to be dealt with
all at once. In extremis, we could defer the code changes by bumping the
version mentioned in the annotation....
One consequence of this approach would be that merging from master to master-1
might would get messier, but it's not at all clear to me how much messier...
> Removed deprecated code in solr/core (master only)
> --------------------------------------------------
>
> Key: SOLR-14469
> URL: https://issues.apache.org/jira/browse/SOLR-14469
> Project: Solr
> Issue Type: Sub-task
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> I'm currently working on getting all the warnings out of the code, so this is
> something of a placeholder for a week or two.
> There will be sub-tasks, please create them when you start working on a
> project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
