hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: Backporting to active branches
Date Fri, 12 Feb 2016 18:23:38 GMT
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 <andrew.purtell@gmail.com>
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 <jon@cloudera.com> 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 <ndimiduk@apache.org>
> 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 <eclark@apache.org>
> 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 <apurtell@apache.org>
> >>> 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 <eclark@apache.org>
> >>>> wrote:
> >>>>
> >>>>> On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell <
> >>>> andrew.purtell@gmail.com>
> >>>>> 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
> > // jon@cloudera.com // @jmhsieh
>



-- 
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message