'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 <j...@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 <ndimi...@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 <ecl...@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 <apurt...@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 <ecl...@apache.org> >>>> wrote: >>>> >>>>> On Thu, Feb 11, 2016 at 1:13 PM, Andrew Purtell < >>>> andrew.purt...@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 > // j...@cloudera.com // @jmhsieh
