Thanks for taking this up, Bharath. Personally I'd lean toward doing the
1.7.1 release to get the other fixes released, since I'm not sure how many
1.7 line releases there will be, and some of those fixes are important for
replication correctness.

Geoffrey

On Thu, Jul 1, 2021 at 1:40 PM Bharath Vissapragada <[email protected]>
wrote:

> Hi,
>
> As some of you may know, we have an incompatible serialization backport
> that landed in 1.7.0 (courtesy of yours truly) that is causing upgrade
> issues (thanks to Viraj for noticing it, more details in HBASE-26021
> <https://issues.apache.org/jira/browse/HBASE-26021>). We have to withdraw
> the release so as to not let 1.x users upgrade to it and instead do another
> release in the same line. We can either do a 1.7.0.1 (= 1.7.0 + HBASE-26021
> fix) or do a 1.7.1 which includes all the commits since 1.7.0 which is
> fairly small (listed below).
>
> ==== delta since 1.7.0 release =====
> 7d0a72be14 (origin/branch-1) HBASE-22923 min version of RegionServer to
> move system table regions (#3438)
> 28f36f4619 HBASE-26021: Undo the incompatible serialization change in
> HBASE-7767 (#3435)
> 395eb0c8e0 HBASE-25130 - Fix master in-memory server holding map after:
> (#3402)
> b2f8ec993e HBASE-26025 Add a flag to mark if the IOError can be solved by
> retry in thrift IOError (#3429)
> fd2f8a581f HBASE-26013 Get operations readRows metrics becomes zero after
> HBASE-25677 (#3410)
> 7e57fecda8 HBASE-21674:Port HBASE-21652 (Refactor ThriftServer making
> thrift2 server inherited from thrift1 server) to branch-1 (#2941)
> 5263b8cf40 HBASE-26004: port HBASE-26001 (cell level tags invisible in
> atomic operations when access control is on)to branch-1 (#3387)
> 2e24bad826 HBASE-25984: Avoid premature reuse of sync futures in FSHLog
> (#3371) (#3398)
> a40f4583e3 Set version on branch-1 to 1.7.1-SNAPSHOT
> 0fd6eeb012 HBASE-25910 - Fix port assignment test (#3308)
> 782e24bd9b HBASE-25924 Re-compute size of WAL file while removing from
> WALEntryStream (#3316)
> =============================
>
> One of these (marked in red above) is a critical fix that was causing us
> issues, so I'd prefer to include it in either of the paths we take. Andrew
> was suggesting 1.7.0.1 in the jira comments (correct me if your definition
> of 1.7.0.1 is different than mine) while I'm leaning towards doing a 1.7.1
> since the delta is fairly small. Thoughts?
>
> I'm happy to be an RM for this release unless there is any objection.
>
> Thanks,
> Bharath
>

Reply via email to