-Re: Does compatibility between versions also mean binary compatibility?
>From my point of view the most important thing is that there's no business
downtime when upgrading between versions (excluding the singularity). That
means there needs to be some path to go from (User Code for 0.92 + 0.92
HBase Servers) to (User Code for 0.94 + 0.94 HBase servers) with no down
>From 0.92 to 0.94 that path would be:
Roll restart HBase to 0.94
Write new User code for 0.94
Deploy new User Code that was written against 0.94
Keeping the changes to a minimum is great but I would rather have the
freedom to fix/add things that are needed.
On Fri, Apr 5, 2013 at 10:12 AM, Jean-Daniel Cryans <[EMAIL PROTECTED]>wrote:
> Good points James.
> I think that regarding binary compatibility, we need to be at least
> backward compatible.
> If I understand your first point correctly, code that compiles against
> 0.94.4 to use the new features added there wouldn't even compile against
> 0.94.3, and I find this reasonable. I'm pretty sure that most here think
> the same way.
> On Thu, Apr 4, 2013 at 4:29 PM, James Taylor <[EMAIL PROTECTED]>
> > The binary compat is a slippery slope. It'd be a bummer if we couldn't
> > take advantage of all the innovation you guys are doing. At the same
> > it's tough to require the Phoenix user community, for example, to upgrade
> > their HBase servers to be able to move to the latest version of Phoenix.
> > don't know what the right answer is, but here are a couple of concrete
> > cases:
> > - between 0.94.3 and 0.94.4, new methods were introduced on
> > Often coprocessors will have their own implementation of these so that
> > can aggregate in the postScannerOpen. Though this broke binary compat, it
> > improved scan performance as well. Where does the binary compatible line
> > stop?
> > - between 0.94.3 and 0.94.4, the class loading changed for coprocessors.
> > If a coprocessor was on the classpath, it didn't matter what the jar path
> > was, it would load. In 0.94.4, that was no longer the case - if the jar
> > path was invalid, the coprocessor would no longer load. Though this broke
> > compatibility, it was a good cleanup for the class loading logic. Call
> it a
> > bug fix or a change in behavior, but either way it was an incompatible
> > change. Is a change in behavior that causes incompatibilities still meet
> > the binary compatible criteria?
> > - between 0.94.4 and 0.94.5, the essential column family feature was
> > introduced. This is an example of one that is binary compatible. We're
> > to take advantage of the feature and maintain binary compatibility with
> > 0.94.4 (in which case the feature simple wouldn't be available).
> > Maybe if we just explicitly identified compatibility issues, that would
> > a good start? We'd likely need a way to find them, though.
> > James
> > On 04/04/2013 03:59 PM, lars hofhansl wrote:
> >> I agree we need both, but I'm afraid that ship has sailed.
> >> It's not something we paid a lot of attention to especially being
> >> forward-binary-compatible. I would guess that there will be many more of
> >> these issues.
> >> Also, we have to qualify this statement somewhere. If you extend
> >> HRegionServer you cannot expect compatibility between releases. Of
> >> that is silly, but it serves the point I am making.
> >> For client visible classes (such as in this case) we should make it
> >> we identifies issues with Filters and Coprocessors in the past and kept
> >> them binary compatible on a best effort basis.
> >> TL;DR: Let's fix this issue, and be wary of more such issues.
> >> -- Lars
> >> ______________________________**__
> >> From: Andrew Purtell <[EMAIL PROTECTED]>
> >> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> >> Sent: Thursday, April 4, 2013 3:21 PM
> >> Subject: Re: Does compatibility between versions also mean binary
> >> compatibility?