Hudson commented on HBASE-17730:

Results for branch HBASE-19064
        [build #90 on 
(x) *{color:red}-1 overall{color}*
details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 

(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 

(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 

(/) {color:green}+1 source release artifact{color}
-- See build output for details.

> [DOC] 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
>            Assignee: Appy
>            Priority: Blocker
>             Fix For: 2.0.0
>         Attachments: HBASE-17730.master.001.patch
> 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

Reply via email to