On Thu, Apr 14, 2016 at 10:25 AM, Stack <st...@duboce.net> wrote: > On Thu, Apr 14, 2016 at 8:59 AM, Andrew Purtell <apurt...@apache.org> > wrote: > > > I think a major version increment is when we've allowed ourselves leeway > to > > make breaking changes. If we were to do this though I'd like to see us > roll > > in as many as we can at once. > > > > > Agreed. > > I suppose I'm opening the flood gates so bring on your CP changes in time > for 2.0! > > > > > By the way, we are still sometimes breaking CPs without meaning to. I > think > > we messed up the RpcScheduler LimitedPrivate interface in 1.2 with > > HBASE-15146, which added a return type to RpcScheduler#dispatch, and > breaks > > Phoenix. Would you lot be interested in setting up a Jenkins job that > uses > > Phoenix to watch for accidental breakage? It's not comprehensive of > course > > but might be the closest available thing to it. > > > > > Probably no harm. Phoenix would be the canary. As long as someone looks at > it though? It'd be branch-1 job? > > Yeah, it would run against branch-1. Let me ask over on dev@phoenix if they want to set up and tend the job. Failure mails would come over to builds@hbase though. I'd ask them to copy me because I can't handle builds@ traffic but would be specifically interested in Phoenix breakage. Sound reasonable?
> St.Ack > > > > > > > > On Thu, Apr 14, 2016 at 8:50 AM, Stack <st...@duboce.net> wrote: > > > > > We cool w/ this? > > > > > > (I know we keep saying it over and over again that its fine to break > CPs > > > w/o deprecation but still uneasy doing the actual breakage.... hence > the > > > note here.) > > > > > > St.Ack > > > >
