The criteria we use for branches >= 1.0 I think addresses this concern. Remember: For 0.98, each 0.98.x is a new _minor_ release. For each 1.1.x each new release is a _patch_ release. So it's likely that features make it in to 0.98, because - new minors; but unlikely features make it into 1.1.x, because - only a patch release.
On Thu, Feb 11, 2016 at 10:33 AM, Elliott Clark <ecl...@apache.org> wrote: > I disagree. We should encourage people to keep up with releases otherwise > things will become un-tenable. > I would vote that we should push back critical and blocker bug fixes to 1.1 > but small fixes should go in the active 1.X branch. The number of patches > that we backport makes the "stable" branches less stable. > > On Thu, Feb 11, 2016 at 9:13 AM, Andrew Purtell <andrew.purt...@gmail.com> > wrote: > > > Thanks Nick. Since you've asked I'll give 1.1 the same treatment. About > > once or twice a month I sweep branch-1 for changes suitable for picking > > back further. You have asked for patches for branch-1.1 to be posted to > > respective issues. I can stop with that or do the same with 1.1 that I've > > done with 0.98: if the patch applies cleanly or with minor fixup, > relevant > > sampled subset of unit tests pass, and the API compat checker says ok, > then > > I apply and push it directly. > > > > > On Feb 11, 2016, at 9:03 AM, Nick Dimiduk <ndimi...@apache.org> wrote: > > > > > > Heya folks, > > > > > > I'm sorry to say branch-1.1 is falling behind in terms of backporting > > fixes > > > and performance improvements. Anything that's not a new feature and > that > > > doesn't break our compatibility guidelines is explicitly acceptable and > > > *should* be backported to the active release branches, 0.98 and > > branch-1.1. > > > Mr. Purtell does a lot of good work to keep up 0.98; I'm afraid I don't > > > have the bandwidth to pursue the commit logs so diligently. > > > > > > Let's change our relationship slightly, dev community. If you're > working > > on > > > a fix, please also post a patch for branch-1.1. By policy, that's > > anything > > > that's not a new feature. I'll veto anything that doesn't hold the > > > compatibility guidelines. The other PMC know the guidelines as well, so > > if > > > you're unsure you don't even have to wait on me -- ask any of them. You > > can > > > even guess whether I'm going to veto it through a quick review of our > > > guidelines [0] and by running your patch through the compatibility > > checker > > > [1]. It only takes a few extra minutes and it will ensure a reasonable > > > shelf-life for our release lines. > > > > > > Thanks a lot for all your effort, > > > Nick > > > > > > [0]: http://hbase.apache.org/book.html#hbase.versioning.post10 > > > [1]: > > > > > > https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=blob;f=dev-support/check_compatibility.sh;h=95dba003a60236e9911af9730654ded6977fe800;hb=refs/heads/master > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
