hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: Backporting to active branches
Date Fri, 12 Feb 2016 19:12:27 GMT
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 <jon@cloudera.com> 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 <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
View raw message