From dev-return-81899-archive-asf-public=cust-asf.ponee.io@hbase.apache.org Fri Dec 4 19:19:59 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org [3.227.148.255]) by mx-eu-01.ponee.io (Postfix) with ESMTPS id 586BC180654 for ; Fri, 4 Dec 2020 20:19:59 +0100 (CET) Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mxout1-ec2-va.apache.org (ASF Mail Server at mxout1-ec2-va.apache.org) with SMTP id 9476346824 for ; Fri, 4 Dec 2020 19:19:58 +0000 (UTC) Received: (qmail 15512 invoked by uid 500); 4 Dec 2020 19:19:57 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 15500 invoked by uid 99); 4 Dec 2020 19:19:57 -0000 Received: from mailrelay1-he-de.apache.org (HELO mailrelay1-he-de.apache.org) (116.203.21.61) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Dec 2020 19:19:57 +0000 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by mailrelay1-he-de.apache.org (ASF Mail Server at mailrelay1-he-de.apache.org) with ESMTPSA id EDA623E95C for ; Fri, 4 Dec 2020 19:19:56 +0000 (UTC) Received: by mail-ej1-f41.google.com with SMTP id qw4so10230540ejb.12 for ; Fri, 04 Dec 2020 11:19:56 -0800 (PST) X-Gm-Message-State: AOAM530KTp+mc90c1ex9GtA6BnbEgySWapiQ4iSUHVjq9azrleOan+Ys 14oXlenSwUQEfc0T2us1BxAC/Thqbg+bSN2SI6A= X-Google-Smtp-Source: ABdhPJwB2te3L0mYDK/Bsfb6et/iXhi91c2mWqwaxCzAnMnsTxiHRBHNQ+YxWC3E1Ezz+XCbwuvowLmTfSb7wsy6Hnc= X-Received: by 2002:a17:906:2b95:: with SMTP id m21mr8752195ejg.134.1607109596071; Fri, 04 Dec 2020 11:19:56 -0800 (PST) MIME-Version: 1.0 References: <6A1BB3EB-74AF-4041-8274-2F44B090B22C@gmail.com> In-Reply-To: <6A1BB3EB-74AF-4041-8274-2F44B090B22C@gmail.com> From: Nick Dimiduk Date: Fri, 4 Dec 2020 11:19:39 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available To: hbase-dev Content-Type: multipart/alternative; boundary="00000000000096d06005b5a85c1b" --00000000000096d06005b5a85c1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable From the section "11.1. Aspirational Semantic Versioning" [0], under the heading "Client Binary compatibility", we say: > If a Client implements an HBase Interface, a recompile MAY be required upgrading to a newer minor version (See release notes for warning about incompatible changes). All effort will be made to provide a default implementation so this case should not arise. This RC contains a change to client-facing API, not to an HBase interface. However, I think this guidance holds for all means of consuming the client API. Thus, my position is that this API change from HBASE-25242 is acceptable under our terms of MINOR release compatibility, and that the section of the book that I have cited should be updated, from "If a Client implements an HBase Interface, ..." to "For any downstream code that consumes an HBase IA.Public API, ..." Thanks, Nick [0]: https://hbase.apache.org/book.html#hbase.versioning.post10 On Fri, Dec 4, 2020 at 9:15 AM Andrew Purtell wrote: > This is a borderline change so I left it in but expected this discussion. > Changing the return type of a method causes a binary incompatibility but > not a source incompatibility. Making a compatibility method is difficult = in > this case because although the return type is considered part of the meth= od > signature the Java compiler only looks at parameters when deciding if a > method duplicates another. So we can=E2=80=99t have the old method return= ing void > and the new one returning Result in the same interface. The new method > returning Result must also define additional parameters or accept a > parameter of a different type. (At least, this is what I recall from > earlier work, would be great if I=E2=80=99m wrong.) RowMutations is I wou= ld expect > relatively uncommonly used. Finally, as an API improvement project this i= s > important work. So I come down on the side of considering this an allowab= le > change. That said, if the consensus is that it is not, it should be > straightforward to change this method=E2=80=99s return type back to void = and spin a > new RC. > > > > On Dec 3, 2020, at 11:04 PM, =E5=BC=A0=E9=93=8E = wrote: > > > > =EF=BB=BFI think for a minor release, we do not expect a drop-in replac= ement, so > > changing the return value from void is fine? You do not need to change > your > > code, just need to recompile it. > > > > Thanks. > > > > Stack =E4=BA=8E2020=E5=B9=B412=E6=9C=884=E6=97=A5=E5= =91=A8=E4=BA=94 =E4=B8=8B=E5=8D=881:58=E5=86=99=E9=81=93=EF=BC=9A > > > >> +0 for now until my question below gets an answer. > >> > >> Signature is good, hash is good. CHANGES and RELEASENOTES look good to= o. > >> Built from the src tgz. Artifact looks right when I untar it. > >> Started it in standalone mode. > >> UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time > >> statistics'... nice). > >> Loaded 10M rows w/ pe. Read them back out again. > >> I've been running unit tests over the last few days. There are flakies > that > >> I've been trying > >> to fix as I see them (HBASE-25353 is latest). I'll keep at it but don'= t > see > >> the last few as > >> cause to hold up the RC (NIghtlies on branch-2 have been pretty good o= f > >> late, see > >> > >> > https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job= /branch-2/ > >> ). > >> > >> Here is my question (Tosihrio?): > >> > >> Looking at API changes, this change looks problematic for a minor > release: > >> > >> hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class > >> package org.apache.hadoop.hbase.client > >> [=E2=88=92] Table.mutateRow ( RowMutations rm ) *:* void 1 > >> > >> > org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/= client/RowMutations;)V > >> > >> ChangeEffect > >> 1 Return value type has been changed from *void* to *Result*. This > method > >> has been removed because the return type is part of the method > signature. A > >> client program may be interrupted by *NoSuchMethodError* exception. > >> > >> Done here.... > >> > >> commit 3775464981b473599c6d1bb24a7eea3badf0ed03 > >> Author: Toshihiro Suzuki > >> Date: Fri Nov 27 03:53:19 2020 +0900 > >> > >> HBASE-25242 Add Increment/Append support to RowMutations (#2711) > >> > >> Signed-off-by: Duo Zhang > >> Signed-off-by: Andrew Purtell > >> > >> The issue is called out as an incompatible change. I don't see > discussion > >> on why this is ok in the PRs. Was I looking in right place? > >> > >> S > >> > >>> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell > wrote: > >>> > >>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1 > >>> > >>> The VOTE will remain open for at least 72 hours. > >>> > >>> [ ] +1 Release this package as Apache hbase 2.4.0 > >>> [ ] -1 Do not release this package because ... > >>> > >>> The tag to be voted on is 2.4.0RC1: > >>> > >>> https://github.com/apache/hbase/tree/2.4.0RC1 > >>> > >>> The release files, including signatures, digests, as well as CHANGES.= md > >>> and RELEASENOTES.md included in this RC can be found at: > >>> > >>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/ > >>> > >>> Customarily Maven artifacts would be available in a staging repositor= y. > >>> Unfortunately I was forced to terminate the Maven deploy step after > >>> the upload ran for more than four hours and my build equipment > >>> needed to be relocated, with loss of network connectivity. This RC ha= s > >>> been delayed long enough. A temporary Maven repository is not a > >>> requirement for a vote. I will retry Maven deploy tomorrow. I can > >>> promise the artifacts for this RC will be staged in Apache Nexus and > >>> ready for release well ahead of the earliest possible time this vote > >>> can complete. > >>> > >>> Artifacts were signed with the apurtell@apache.org key which can be > >> found > >>> in: > >>> > >>> https://dist.apache.org/repos/dist/release/hbase/KEYS > >>> > >>> The API compatibility report for this RC can be found at: > >>> > >>> > >>> > >>> > >> > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC= 1_to_2.3.0.html > >>> > >>> The changes are mostly added methods, which conform to the > compatibility > >>> guidelines for a new minor release. There is one change to the public > >>> Region interface that alters the return type of a method. This is > >>> equivalent to a removal then addition and can be a binary compatibili= ty > >>> problem. However to your RM's eye the change looks intentional and is > >>> part of an API improvement project, and a compatibility method is not > >>> possible here because Java doesn't consider return type when deciding > if > >>> one method signature duplicates another. > >>> > >>> To learn more about Apache HBase, please see > >>> > >>> http://hbase.apache.org/ > >>> > >>> Thanks, > >>> Your HBase Release Manager > >>> > >> > --00000000000096d06005b5a85c1b--