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 > > > > > >
