hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@apache.org>
Subject Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available
Date Fri, 04 Dec 2020 19:19:39 GMT
>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.purtell@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, 张铎 <palomino219@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 <stack@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 <brfrn169@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 <zhangduo@apache.org>
> >>    Signed-off-by: Andrew Purtell <apurtell@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 <apurtell@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 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.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
> >>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message