There are still lots of small new features which we want to integrate into branch-2 so I'm -1 on making release directly from branch-2. Backporting at once before release is a pain I'd say, I've tried this many times recently, as we have to follow up the community version...Let's make a branch-2.2 when we want to release 2.2.0, and maybe also retire the branch-2.0?
For the stable pointer, I think 2.1.x maybe a good candidate? Though we know that we may still have some bugs for the AMv2, but actually we all know that the AMv1 for all the branch-1.x also has lots of bugs, that's why hbck is very important. And also +! on making progress on HBCK2, we need to port he useful features of HBCK1 to HBCK2. There is no software can guarantee that there is no bug, so FWIW we should have a way to fix broken clusters. Sean Busbey <bus...@apache.org> 于2019年1月18日周五 上午11:47写道： > 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? >
