I went back to our semantic versioning write-up and see in the 'Client Binary Compatibility' section:
"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." See http://hbase.apache.org/book.html#hbase.versioning.post10 This text is more constraining than drop-in replacement -- i.e. client implements an HBase Interface -- but would allow that minor updates may require recompiles. I think it enough. I change my vote to +1 on RC0. S 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 > >>> > >> >
