You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Appy (JIRA)" <ji...@apache.org> on 2017/03/04 00:40:45 UTC
[jira] [Created] (HBASE-17730) Migration to 2.0 for coprocessors
Appy created HBASE-17730:
----------------------------
Summary: Migration to 2.0 for coprocessors
Key: HBASE-17730
URL: https://issues.apache.org/jira/browse/HBASE-17730
Project: HBase
Issue Type: Sub-task
Reporter: Appy
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, but the fix is actually just one line : simply change "Foo extends BaseXXXObserver" to "Foo implements XXXObserver".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)