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 <j...@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.purt...@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 <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 > > > > -- > // Jonathan Hsieh (shay) > // HBase Tech Lead, Software Engineer, Cloudera > // j...@cloudera.com // @jmhsieh
