But, since that some users may already have their production system on HBase-2.0.x, maybe we should consider their feelings, they are the 'first movers'. If we retire branch-2.0 so quickly, IIRC, the branch-2.0 will be the shortest life branch ever. I think it will hurt the feeling of those 'first movers'. If we take this into count, then I think maybe we should keep branch-2.0 at least one year. If the community is shorthanded, I volunteer to take responsible to decide/backport/release branch-2.0 since I was working on this branch most recently. Anyway, this thread is about releasing HBase2.2.x, I will vote a +1 for it, as for HBase-2.0.x, we can discuss later. Best Regards Allan Yang
Allan Yang <allan...@apache.org> 于2018年11月12日周一 上午10:12写道： > Stack, are you suggest about retiring branch-2.0? I think it is OK, since > branch-2.0 is almost the same with branch-2.1 now(except some new feature > on replication). Yes, agree that we should help out on branch-2.2. AMv2 > changed a lot in branch-2, there may still have some work to do to make > branch-2.2 stable. But at same time, I think we can mark branch-2.1 as > stable. We have done tremendous work on this branch, and recently ITBLLs > shows it is already stable enough(based on our internal version, but most > of patches in branch-2.1 was backported) > Best Regards > Allan Yang > > > Stack <st...@duboce.net> 于2018年11月12日周一 上午6:57写道： > >> Agree w/ Duo that the 2.x releases have been gated on stability watersheds >> rather than features. >> >> What else do we need to add to HBCK2 Duo (apart from a release)? >> >> Related, I was going to work on a 2.0.3 release. It has been a while and a >> bunch of good stability work has made it into branch-2.0. Thereafter >> though, I was going to let branch-2.0 go unless demand -- Allan Yang? -- >> and switch instead to helping out on branch-2.2. >> >> S >> >> On Thu, Nov 8, 2018 at 6:10 PM 张铎(Duo Zhang) <palomino...@gmail.com> >> wrote: >> >> > I think for the 2.x release the problem is that we are still busy on >> making >> > the code stable, or speak more clearly, to make the procedure v2 >> framework >> > stable... And another big problem is lacking of HBCK2 support. These >> things >> > are all big issues which prevent people to upgrade to 2.x. >> > >> > Once these things are done, I think a monthly release will not be a big >> > problem to the RMs. Just simply run an ITBLL(for now it is not easy to >> get >> > a successful run and then we need to find out why...), and then the >> > make_rc.sh can not everything for you... >> > >> > Sean Busbey <bus...@apache.org> 于2018年11月9日周五 上午9:45写道： >> > >> > > I think it just shifts the RM burden, no? Like instead of watching >> e.g. >> > > branch-2.2 I instead need to watch branch-2. >> > > >> > > On Thu, Nov 8, 2018, 17:28 Josh Elser <els...@apache.org wrote: >> > > >> > > > I think what I'd be concerned about WRT time-based releases is the >> > > > burden on RM to keep the branch in a good state. Perhaps we need to >> not >> > > > push that onto an RM and do better about sharing that load (looking >> in >> > > > the mirror). >> > > > >> > > > However, I do like time-based releases as a means to avoid "hurt >> > > > feelings" (e.g. the personal ties of a developer to a feature. "The >> > > > release goes out on zzzz/yy/xx, this feature is not yet ready, can >> go >> > > > out one month later.." etc) >> > > > >> > > > On 11/7/18 2:31 PM, Sean Busbey wrote: >> > > > > Hi folks! >> > > > > >> > > > > Some time ago we talked about trying to get back on track for a >> more >> > > > > regular cadence of minor releases rather than maintenance releases >> > > > > (like how we did back pre-1.0). That never quite worked out for >> the >> > > > > HBase 1.y line, but is still something we could make happen for >> HBase >> > > > > 2. >> > > > > >> > > > > We're coming up on 4 months since the 2.1 release line started. >> ATM >> > > > > there are 63 issues in JIRA that claim to be in 2.2.0 and not in >> any >> > > > > 2.1.z version[1]. >> > > > > >> > > > > The main argument against starting to do a 2.2.0 release is that >> > > > > nothing springs out of that list as a "feature" that would entice >> > > > > users to upgrade. Waiting for these kinds of selling points to >> drive >> > a >> > > > > release is commonly referred to as "feature based releases." I >> think >> > > > > it would be fair to characterize the HBase 2.0 release as feature >> > > > > based centered on AMv2. >> > > > > >> > > > > An alternative to feature based releases is date based releases >> where >> > > > > we decide that e.g. we'll have a minor release each month >> regardless >> > > > > of how much is included in it. This is sometimes also called >> "train >> > > > > releases" as an analogy to how trains leave a station on a set >> > > > > schedule without regard to which individual passengers are ready. >> > Just >> > > > > as you'd catch the next scheduled train if you miss-timed your >> > > > > arrival, fixes or features that aren't ready just go in the next >> > > > > regular release. >> > > > > >> > > > > Personally, I really like the idea of doing date based releases >> for >> > > > > minor releases with maintenance releases essentially only >> happening >> > on >> > > > > whatever our "stable" designator points at. It would mean those >> who >> > > > > don't want the risk and benefits of our current release-ready work >> > > > > could stay on a defined path while we could move away from >> > maintaining >> > > > > a ton of branches, some of which don't even see releases >> (currently >> > ~3 >> > > > > that are > 3 months since a release). If some folks had a specific >> > > > > need for a different minor release line and were willing to do the >> > > > > backport and RM work for that line, they'd of course be free to do >> > so. >> > > > > >> > > > > I know there are some current unknowns around 2.2 specifically. I >> > > > > think stack mentioned to me that there's an upgrade consideration >> > that >> > > > > we need to hammer out since I don't see anything specific to 2.2 >> in >> > > > > the "Upgrade Paths" section of the ref guide right now. While I am >> > > > > interested in getting 2.2 going specifically, I'd like to make >> sure >> > we >> > > > > address the general topic of regularly getting new minor releases >> > out. >> > > > > If we already had an expectation that there'd be a minor release >> > every >> > > > > e.g. month or 2 months then I expect whatever upgrade issue would >> > have >> > > > > been addressed as a part of the change that caused it going in. >> > > > > >> > > > > What do folks think? >> > > > > >> > > > > [1]: >> > > > > https://s.apache.org/AAma >> > > > > >> > > > >> > > >> > >> >
