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 method signature the Java compiler only looks at parameters when deciding if a method duplicates another. So we can’t have the old method returning 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’m wrong.) RowMutations is I would expect relatively uncommonly used. Finally, as an API improvement project this is important work. So I come down on the side of considering this an allowable change. That said, if the consensus is that it is not, it should be straightforward to change this method’s return type back to void and spin a new RC.
> On Dec 3, 2020, at 11:04 PM, 张铎 <palomino...@gmail.com> wrote: > > I think for a minor release, we do not expect a drop-in replacement, so > changing the return value from void is fine? You do not need to change your > code, just need to recompile it. > > Thanks. > > Stack <st...@duboce.net> 于2020年12月4日周五 下午1:58写道： > >> +0 for now until my question below gets an answer. >> >> Signature is good, hash is good. CHANGES and RELEASENOTES look good too. >> 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 of >> 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 >> [−] 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 <brfrn...@gmail.com> >> Date: Fri Nov 27 03:53:19 2020 +0900 >> >> HBASE-25242 Add Increment/Append support to RowMutations (#2711) >> >> Signed-off-by: Duo Zhang <zhang...@apache.org> >> Signed-off-by: Andrew Purtell <apurt...@apache.org> >> >> 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 <apurt...@apache.org> 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 repository. >>> 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 has >>> 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 apurt...@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.0RC1_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 compatibility >>> 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 >>> >>
