> 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,
This is a bit premature to say never. I've been making steady releases of 1.4 and am about to spin 1.5.0, a new branch branch-1.5. After 1.4.9 the next release from 1.x will probably be 1.5.0. Point taken though, more frequent minors from 1.x, as discussed. (On the other hand the backports to 1.x have slowed significantly, as actually we might hope with a focus on 2.0 and up going forward. So maybe a minor after 1.5 won't be necessary. Time will tell.) On Wed, Nov 7, 2018 at 11:31 AM Sean Busbey <bus...@apache.org> 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 > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
