[
https://issues.apache.org/jira/browse/HBASE-17730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16175043#comment-16175043
]
stack commented on HBASE-17730:
-------------------------------
Yes is answer to your question above [~anoop.hbase] -- smile.
I have list of incompatibilities for coprocessors running here
https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_ktczrlKHK8N4SZzs/edit#heading=h.9k7mjbauv0wj
but this issue is about more than just list of breakage; it is about adding
section to 2.0 migration on how to move coprocessors over.
> Migration to 2.0 for coprocessors
> ----------------------------------
>
> Key: HBASE-17730
> URL: https://issues.apache.org/jira/browse/HBASE-17730
> Project: HBase
> Issue Type: Sub-task
> Components: documentation, migration
> Reporter: Appy
> Priority: Blocker
> Fix For: 2.0.0
>
>
> Jiras breaking coprocessor compatibility should be marked with component '
> Coprocessor', and label 'incompatible'.
> Close to releasing 2.0, we should go through all such jiras and write down
> steps for migrating coprocessor easily.
> The idea is, it might be very hard to fix coprocessor breakages by reverse
> engineering errors, but will be easier we suggest easiest way to fix
> breakages resulting from each individual incompatible change.
> For eg. HBASE-17312 is incompatible change. It'll result in 100s of errors
> because BaseXXXObserver classes are gone and will probably result in a lot of
> confusion, but if we explicitly mention the fix which is just one line change
> - replace "Foo extends BaseXXXObserver" with "Foo implements XXXObserver" -
> it makes it very easy.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
