Responses to several threads below, sorry in advance to folks that with mail readers this will mess up.
On Wed, Nov 14, 2018 at 7:35 PM Andrew Purtell <[email protected]> wrote: > > > 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.) > That's reenforcing my point though isn't it? We have done a good job of keeping up maintenance releases. In February it'll be 4 years since 1.0.0 and we're about to hit a fifth minor release. We've done nearly 40 maintenance releases. By comparison the 0.98 major version line lasted just shy of 3 years, had 24 minor releases, and just a handful of maintenance releases. We're 6 months into the HBase 2 release line. I'd like to start bending things closer to 0.98's pattern. On Sun, Nov 11, 2018 at 8:12 PM Allan Yang <[email protected]> wrote: > > 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) The bit about "AMv2 changed in branch-2" is part of what worries me. I get that branch-2 releases haven't been as stable as branch-1 was, but I think the key to avoiding too much pain as folks who want to be on the newer side of things is to 1) minimize the incremental upgrade cost across minor releases and 2) minimize the number of branches we're trying to maintain as a project, because we don't have infinite dev bandwidth and test resources. Would it be so much worse for folks if there were a regular cadence of e.g. "new minor starts on the quarter. maintenance for it until the next minor"? They're still getting incrementally more stable releases. Part of my desire here is specifically to change how we think about i.e. "branch-2" so that folks don't take the liberty of backporting things before they are low-risk. Instead of having an RM punting things out of branch-2.y because their regular ITBLL got wonky they'd be punting things out of branch-2. We're a do-acracy, so as a reminder literally anyone could show up and be like "I'm personally going to handle maintenance releases for 2.7 because I don't want any more features" and at a minimum we'd work them through doing releases (probably making them a PMC in the process to maximize how much of the work they could do themselves). Probably they'd have to be willing to handle any non-trivial backports, or at least ping contributors to provide one. On Fri, Nov 9, 2018 at 9:57 AM Josh Elser <[email protected]> wrote: > > Yes, agreed. My comment was more aimed at getting someone to "sign-up" > to do the work, regardless or what branch they're watching. > > I'd be in favor of trying it out, see how it works. What's the worst > that happens, we re-evaluate in three months? :shruggie: > Indeed. Let me try to get something written down about trying things out and see if folks are game. I'll find out soon if my expectations of the work burden for ongoing 1.2.z releases are realistic. If they are I might be willing/able to be the sign-ee.
