There are a few related topics I'd like to discuss and I figured this subject line is the most likely to get a bit of attention. :)
First, I'd like us all to get on the same page wrt the current state of branch-2. Personally, I don't think it can be released as-is with a 2.y version because folks can't rolling upgrade from 2.0 or 2.1 to it due to the current implementation of HBASE-20881. As Duo has mentioned a couple of times, folks have to ensure there are no region transitions around during the upgrade. I think that will be prohibitive for folks looking to upgrade. What do other folks think? Second, I think our recent discussions around the need for shifting to more minor releases for HBase 1.y also applies to the 2.y branches. branch-2 hasn't had a release since 2.1.0 came out in July 2018. That's a scary long amount of time. I think it contributes to us ending up with changes like the above since it's easy to think about the branch as something that has a lot of time before the next release. Personally, I'd like to see us skip making minor-release specific branches for a bit unless a CVE fix or something comes up. Ideally, that would mean we work towards a 2.2.0 release directly from branch-2 and then 2.2.1, etc. When we have a feature that's ready to backport from the master branch for a release we then update branch-2's version to be 2.3.0. Or maybe we try set a regular cadence to feature releases by having branch-2 release a new minor, two months of new maintenance releases, followed by a new minor. That would mean after the last of the maintenance releases we'd have a window of a few weeks where we can all decide which features in master are mature enough to backport for the new minor release. Lastly, what would it take for folks to feel confident moving the 'stable' pointer to a HBase 2.y? Is there a major gap still on assignment stability? Is it a more thorough look at performance? More time to ensure HBCK2 has good coverage of failure modes that need it?
