Thank you for raising the discussion. I thought changing the return type of the mutateRow method from void to Result in HBASE-25242 didn’t violate our release policy according to the doc some guys already mentioned. And looks like that was already agreed.
Thanks, Toshihiro Suzuki > On Dec 5, 2020, at 4:19, Nick Dimiduk <ndimi...@apache.org> wrote: > > 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 <andrew.purt...@gmail.com> > 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 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 >>>>> >>>> >>
