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 change in patch releases the better. Having said that, there are exceptions to this rule, and it is still ok to backport "improvements" where risk vs reward is pretty obvious.
However, I feel the pain that Nick is talking about in terms of maintaining the backports. ALL committers should be familiar with the general guidelines we follow so that they can judge on a patch-by-patch basis whether to backport or not. All critical / blocker, data loss kind of things should go to all active branches. Other bug fixes, we should again use risk vs reward judgement. Enis On Fri, Feb 12, 2016 at 11:12 AM, Andrew Purtell <[email protected]> wrote: > 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 <[email protected]> wrote: > > > > 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 days, many would effectively have been > > patch releases (e.g.: using snapshots as an example, 94.3, .4, .5 were > > roughly patch releases, and 94.6 which intro'ed snapshots which would > have > > been a minor). We just didn't make it obvious to users back then. > > > > Jon. > > > > > > On Fri, Feb 12, 2016 at 9:42 AM, Andrew Purtell < > [email protected]> > > wrote: > > > >> '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 > >> furthermore our semver-like policy as documented expresses that > >> conservatism when discussing point releases. > >> > >> For minor releases I agree with Nick. Users should benefit from > >> improvements that don't break compatibility as defined by our > guidelines. > >> For example 0.98 is the last release before region replicas. Some might > be > >> shy about upgrading to a release containing this major change but will > >> definitely want perf improvements, operability improvements to tooling, > and > >> such. When something like MOB goes in we'll have another such point. > >> > >> For major releases we have given ourselves leeway to do big things, but > >> that's going to be a case by case discussion, where even so we want to > give > >> users a way to make a smooth transition. > >> > >>> On Feb 11, 2016, at 10:26 PM, Jonathan Hsieh <[email protected]> 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 unknown issues caused of small improvements. > >>> > >>> I prefer the conservative approach with "improvements", and prefer that > >>> maint/point release just backport critical fixes, security fixes, > testing > >>> improvements (test only flakey fixups), recovery tooling (hbck > updates), > >>> and critical perf regression fixes. > >>> > >>> If not getting minors out fast enough is the main concern and > motivator, > >>> I'd argue backporting more doesn't help the problem -- that is energy > >> that > >>> could be spent helping get more minors out more frequently. One of > the > >>> things about having frequent point release like when we had with 0.94 > was > >>> that we likely could have shipped some of the earlier 1.2.0rcs and > fixed > >>> the criticals in next point release train. > >>> > >>> Jon. > >>> > >>>> On Thu, Feb 11, 2016 at 9:45 PM, Nick Dimiduk <[email protected]> > >> wrote: > >>>> > >>>> 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, according to our guidelines. > >>>> > >>>>> On Thu, Feb 11, 2016 at 2:55 PM, Elliott Clark <[email protected]> > >> wrote: > >>>>> > >>>>> 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 them fixed things that we hit in production but they didn't > >>>> change > >>>>> correctness or cause the system to be un-usable in the normal case. > So > >> I > >>>>> would classify them as improvements. For me I would want to backport > >> only > >>>>> for patch releases fixes that fixed severe issues, things that > changed > >>>>> correctness or caused a system to be un-usable. > >>>>> > >>>>> On Thu, Feb 11, 2016 at 1:54 PM, Andrew Purtell <[email protected] > > > >>>>> wrote: > >>>>> > >>>>>> 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 <[email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell < > >>>>>> [email protected]> > >>>>>>> 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. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Best regards, > >>>>>> > >>>>>> - Andy > >>>>>> > >>>>>> Problems worthy of attack prove their worth by hitting back. - Piet > >>>> Hein > >>>>>> (via Tom White) > >>> > >>> > >>> > >>> -- > >>> // Jonathan Hsieh (shay) > >>> // HBase Tech Lead, Software Engineer, Cloudera > >>> // [email protected] // @jmhsieh > > > > > > > > -- > > // Jonathan Hsieh (shay) > > // HBase Tech Lead, Software Engineer, Cloudera > > // [email protected] // @jmhsieh >
