Re: Backporting to active branches

We don't have frequent enough releases with 0.98? > On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh wrote: > > Users also deserve to get as few new surprises as possible. Being on the > supporting side of this, I've come to prefer preserving minor known issues > to having new

Re: Backporting to active branches

I was speaking of the frequency of minor releases on the 1.x line, not 98. On Friday, February 12, 2016, Andrew Purtell wrote: > We don't have frequent enough releases with 0.98? > > > > On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh >

Re: Backporting to active branches

On Fri, Feb 12, 2016 at 9:42 AM, Andrew Purtell wrote: > I think Elliott's point of view is spot on for patch releases and > furthermore our semver-like policy as documented expresses that > conservatism when discussing point releases. > Yeah my concern was really only

Re: Backporting to active branches

I was responding to (Jon) "One of the things about having frequent point release like when we had with 0.94" On Feb 12, 2016, at 9:33 AM, Nick Dimiduk wrote: >>> One of the >>> things about having frequent point release like when we had with 0.94 was >>> that we likely

Re: Backporting to active branches

'Point release' isn't precise enough terminology. We have major, minor, and patch releases: 0.96 -> 0.98 or 1.0 -> 2.0 - major 0.98.0 -> 0.98.1, or 1.0.0 -> 1.1.0 - minor 0.98.0 -> 0.98.0.1, or 1.0.0 -> 1.0.1 - patch I think Elliott's point of view is spot on for patch releases and

Re: Backporting to active branches

I agree with Andrew here. We had a good cadence with 98 -- I didn't mean to exclude. The fast cadence of 94/98 releases was good -- the more recent 1.x lines haven't been as frequent. Using the more precise terminology Andrew suggests-- if we used our new versioning rules back in the 94/98

Re: Backporting to active branches

I think if we tell people to drop the "0." prefix from pre 1.0 versions and squint then it gives a good sense of what can and did happen release to release. > On Feb 12, 2016, at 10:23 AM, Jonathan Hsieh wrote: > > I agree with Andrew here. > > We had a good cadence with

Re: Backporting to active branches

I am in favor of "bug fixes only" changes to the patch releases. In 1.0 release lines, we tried to stick to that, and explicitly did not backport some nice improvements. In many occasions, we had backported some issue thinking that it is harmless, but turned out to be a problem. So, the less

Re: Backporting to active branches

I appreciate Elliot's voice for conservatism on released branches. However I don't think we're getting minor releases out the door fast enough, especially when we have nice "improvements" that apply cleanly. Users deserve to get as many of the improvements as are compatible for patch releases,

Re: Backporting to active branches

Users also deserve to get as few new surprises as possible. Being on the supporting side of this, I've come to prefer preserving minor known issues to having new unknown issues caused of small improvements. I prefer the conservative approach with "improvements", and prefer that maint/point

Re: Backporting to active branches

The criteria we use for branches >= 1.0 I think addresses this concern. Remember: For 0.98, each 0.98.x is a new _minor_ release. For each 1.1.x each new release is a _patch_ release. So it's likely that features make it in to 0.98, because - new minors; but unlikely features make it into 1.1.x,

Re: Backporting to active branches

On Thu, Feb 11, 2016 at 9:03 AM, Nick Dimiduk wrote: > ... > Let's change our relationship slightly, dev community. If you're working on > a fix, please also post a patch for branch-1.1. It is a bit tough. That'd be a patch for four branches (at least), three of which have

Re: Backporting to active branches

On Thu, Feb 11, 2016 at 11:10 AM, Andrew Purtell wrote: > later versions of 0.98 are more stable I would assert that to be because less and less things are applying now. Every time we have tried a new patch version of 1.0 ( We haven't really tried any 1.1 since we've been

Re: Backporting to active branches

I would also quibble about this: > The number of patches that we backport makes the "stable" branches less stable. At least in our production settings, later versions of 0.98 are more stable and perform better than earlier ones as a rule. My experience refutes the above claim, but YMMV On Thu,

Re: Backporting to active branches

> I would assert that to be because less and less things are applying now. ​I'm sure that's true as well (smile) ​ On Thu, Feb 11, 2016 at 11:32 AM, Elliott Clark wrote: > On Thu, Feb 11, 2016 at 11:10 AM, Andrew Purtell > wrote: > > > later versions

Re: Backporting to active branches

Stack wrote: ... > Let's change our relationship slightly, dev community. If you're working on > a fix, please also post a patch for branch-1.1. It is a bit tough. That'd be a patch for four branches (at least), three of which have diverged in key areas (master, branch-1 and branch-1.2, and

Re: Backporting to active branches

That one's on the edge for me. It's trying to work around a bug somewhere that has caused data loss in prod. So I would lean towards it being a bug fix. However pulling from my last few filed jiras I would say these are all improvements: HBASE-15166 HBASE-15146 HBASE-15137 HBASE-15083 Some of

Re: Backporting to active branches

I'd also encourage RMs to make occasional (I try monthly) sweeps of upstream branch history to get a lay of the land and identify changes you think should be in your RC but didn't get there by commit - and pick those back if so. Allow an extra few days when scheduling time to work on that next

Re: Backporting to active branches

The majority of changes in branch-1 that I see are bug fixes. Only committer attention and bandwidth prevents application to all places. A few are new features or bug fixes that break APIs or change behavior in a manner unsuitable for a patch release. Spotting those isn't hard. Finally, it's

Re: Backporting to active branches

On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell wrote: > The majority of changes in branch-1 that I see are bug fixes. I think that's the point that you and I differ. For me I would classify most things on branch-1 as improvements and there are very few bug fixes.

Re: Backporting to active branches

Ok, in fairness there could be more debatable (or even not debatable) changes on branch-1 as you say. Also, a difference of perspective. Would you for example consider HBASE-15211 a bug fix or improvement? On Thu, Feb 11, 2016 at 1:25 PM, Elliott Clark wrote: > On Thu, Feb

Re: Backporting to active branches

Thanks Nick. Since you've asked I'll give 1.1 the same treatment. About once or twice a month I sweep branch-1 for changes suitable for picking back further. You have asked for patches for branch-1.1 to be posted to respective issues. I can stop with that or do the same with 1.1 that I've done

Backporting to active branches

Heya folks, I'm sorry to say branch-1.1 is falling behind in terms of backporting fixes and performance improvements. Anything that's not a new feature and that doesn't break our compatibility guidelines is explicitly acceptable and *should* be backported to the active release branches, 0.98 and

Re: Backporting to active branches

I disagree. We should encourage people to keep up with releases otherwise things will become un-tenable. I would vote that we should push back critical and blocker bug fixes to 1.1 but small fixes should go in the active 1.X branch. The number of patches that we backport makes the "stable"