You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Andrew Purtell <ap...@apache.org> on 2014/02/04 00:08:23 UTC
Binary API compatibility is not a requirement for any 0.98 release candidate
If you would like to change this consensus now, we can do so, and add it as
a release criterion. That would require undoing the comparator cleanups and
related breaking changes that went in as HBASE-9245 and subtasks. So let's
not. I am -1 on making a change like this late in the day, after we have
already had two RCs and I am hoping to get a third out tomorrow.
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Aleksandr Shulman <al...@cloudera.com>.
I realize that this is an evolving product and that we will likely have to
break compatibility as we go. As long as these binary incompatibilities are
non-arbitrary, well documented, and part of a concerted effort (e.g. perf
optimization) to make improvements whose value to the user is greater than
that of having binary compat, then I'm fine with it.
On Tue, Feb 4, 2014 at 3:49 PM, lars hofhansl <la...@apache.org> wrote:
> For what's it worth, I agree with both of you. ;)
>
>
> - A binary compatibility issue should not sink a release.
> - If we want to clean up an API that would lead to an unavoidable binary
> compatibility issue, we should still do it and break binary compatibility.
>
> - If there's an easy fix to retain binary compatibility, let's put these
> in.
>
> As usual, just my $0.02.
>
>
> -- Lars
>
> ________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> To: Andrew Purtell <an...@gmail.com>
> Cc: "dev@hbase.apache.org" <de...@hbase.apache.org>; lars hofhansl <
> larsh@apache.org>; Andrew Purtell <ap...@apache.org>
> Sent: Tuesday, February 4, 2014 3:25 PM
> Subject: Re: Binary API compatibility is not a requirement for any 0.98
> release candidate
>
>
> True. I think the difference here is that the KV stuff and comparator stuff
> was marked that InterfaceAudience.Private for 0.96, and Scan was
> InterfaceAudience.Public/InterfaceStability.Stable for 0.96.
>
> The stronger markings mean we should really enforce the deprecation policy
> in 0.98. .
>
> Jon.
>
>
> On Tue, Feb 4, 2014 at 3:18 PM, Andrew Purtell <andrew.purtell@gmail.com
> >wrote:
>
> > Jon,
> >
> > I find your "ship has sailed here" phrasing a bit odd because it was your
> > changes to KV comparators that kicked off the original discussion on
> binary
> > compatibility and, then, an agreement that binary API compat not be a
> > criteria for 0.98 releases. Otherwise it would have been. :-)
> >
> > On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> >
> > Andrew,
> >
> > I basically agree with lars here -- the ship has sailed here. However,
> > there are some patches that restored binary compat in places committed to
> > 0.98 already. (IMO actually this would be an argument to fork earlier in
> > the future)
> >
> > I have some comments on HBASE-10460. Specifically it is on a class that
> > is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I
> think
> > they fix there should get into 0.98.
> >
> > Jon.
> >
> >
> >
> > On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
> >
> >> My $0.02...
> >>
> >> Wire (client-server and server-server) compatibility is a must have.
> >> Binary compatibility should be a best effort. I.e. we shouldn't go out
> of
> >> our way to break things, but if we want to clean up an API we should do
> >> that.
> >> So much for 0.98.
> >>
> >> Going forward...
> >>
> >> Once we go past version 1.0 and to semantic versioning this will need a
> >> bigger discussion.
> >>
> >> As discussed in the past there are at least four angles here:
> >> 1. Client-server wire compatibility
> >> 2. Server-server wire compatibility
> >> 3. Client binary compatibility
> >> 4. Server interface binary compatibility (for coprocessors)
> >>
> >> #4 is surprisingly important as it basically turns into a #1 problem
> when
> >> a project ships with coprocessors.
> >>
> >> Then we need to define compatibility rules for major/minor/patch
> versions.
> >> In the last PMC meeting we had a start on this. We need to finish the
> >> details.
> >>
> >> -- Lars
> >>
> >>
> >> ----- Original Message -----
> >> From: Andrew Purtell <ap...@apache.org>
> >> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> >> Cc:
> >> Sent: Monday, February 3, 2014 3:08 PM
> >> Subject: Binary API compatibility is not a requirement for any 0.98
> >> release candidate
> >>
> >> If you would like to change this consensus now, we can do so, and add it
> >> as
> >> a release criterion. That would require undoing the comparator cleanups
> >> and
> >> related breaking changes that went in as HBASE-9245 and subtasks. So
> let's
> >> not. I am -1 on making a change like this late in the day, after we have
> >> already had two RCs and I am hoping to get a third out tomorrow.
> >>
> >> --
> >> 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
> > // jon@cloudera.com // @jmhsieh
>
> >
> >
> >
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
>
--
Best Regards,
Aleks Shulman
847.814.5804
Cloudera
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Andrew Purtell <an...@gmail.com>.
As RM for 0.98, I think it's important I do not take a position against
consensus. At the same time, it is only fair that the community should
afford the RM consistency on decision making regarding the release
criteria.
My read of this thread is a vote is not necessary. However, if we
collectively in fact do have cold feet about binary (in)compatibility, I am
more than happy to go with Aleks' report in hand and revert every commit
that intersects with an incompatible API change. Otherwise, then I request
when voting on RCs you do not cast -1 votes on that basis.
On Tue, Feb 4, 2014 at 3:49 PM, lars hofhansl <la...@apache.org> wrote:
> For what's it worth, I agree with both of you. ;)
>
>
> - A binary compatibility issue should not sink a release.
> - If we want to clean up an API that would lead to an unavoidable binary
> compatibility issue, we should still do it and break binary compatibility.
>
> - If there's an easy fix to retain binary compatibility, let's put these
> in.
>
> As usual, just my $0.02.
>
>
> -- Lars
>
> ________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> To: Andrew Purtell <an...@gmail.com>
> Cc: "dev@hbase.apache.org" <de...@hbase.apache.org>; lars hofhansl <
> larsh@apache.org>; Andrew Purtell <ap...@apache.org>
> Sent: Tuesday, February 4, 2014 3:25 PM
> Subject: Re: Binary API compatibility is not a requirement for any 0.98
> release candidate
>
>
> True. I think the difference here is that the KV stuff and comparator stuff
> was marked that InterfaceAudience.Private for 0.96, and Scan was
> InterfaceAudience.Public/InterfaceStability.Stable for 0.96.
>
> The stronger markings mean we should really enforce the deprecation policy
> in 0.98. .
>
> Jon.
>
>
> On Tue, Feb 4, 2014 at 3:18 PM, Andrew Purtell <andrew.purtell@gmail.com
> >wrote:
>
> > Jon,
> >
> > I find your "ship has sailed here" phrasing a bit odd because it was your
> > changes to KV comparators that kicked off the original discussion on
> binary
> > compatibility and, then, an agreement that binary API compat not be a
> > criteria for 0.98 releases. Otherwise it would have been. :-)
> >
> > On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> >
> > Andrew,
> >
> > I basically agree with lars here -- the ship has sailed here. However,
> > there are some patches that restored binary compat in places committed to
> > 0.98 already. (IMO actually this would be an argument to fork earlier in
> > the future)
> >
> > I have some comments on HBASE-10460. Specifically it is on a class that
> > is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I
> think
> > they fix there should get into 0.98.
> >
> > Jon.
> >
> >
> >
> > On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
> >
> >> My $0.02...
> >>
> >> Wire (client-server and server-server) compatibility is a must have.
> >> Binary compatibility should be a best effort. I.e. we shouldn't go out
> of
> >> our way to break things, but if we want to clean up an API we should do
> >> that.
> >> So much for 0.98.
> >>
> >> Going forward...
> >>
> >> Once we go past version 1.0 and to semantic versioning this will need a
> >> bigger discussion.
> >>
> >> As discussed in the past there are at least four angles here:
> >> 1. Client-server wire compatibility
> >> 2. Server-server wire compatibility
> >> 3. Client binary compatibility
> >> 4. Server interface binary compatibility (for coprocessors)
> >>
> >> #4 is surprisingly important as it basically turns into a #1 problem
> when
> >> a project ships with coprocessors.
> >>
> >> Then we need to define compatibility rules for major/minor/patch
> versions.
> >> In the last PMC meeting we had a start on this. We need to finish the
> >> details.
> >>
> >> -- Lars
> >>
> >>
> >> ----- Original Message -----
> >> From: Andrew Purtell <ap...@apache.org>
> >> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> >> Cc:
> >> Sent: Monday, February 3, 2014 3:08 PM
> >> Subject: Binary API compatibility is not a requirement for any 0.98
> >> release candidate
> >>
> >> If you would like to change this consensus now, we can do so, and add it
> >> as
> >> a release criterion. That would require undoing the comparator cleanups
> >> and
> >> related breaking changes that went in as HBASE-9245 and subtasks. So
> let's
> >> not. I am -1 on making a change like this late in the day, after we have
> >> already had two RCs and I am hoping to get a third out tomorrow.
> >>
> >> --
> >> 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
> > // jon@cloudera.com // @jmhsieh
>
> >
> >
> >
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
>
Re: Binary API compatibility is not a requirement for any 0.98 release candidate
Posted by lars hofhansl <la...@apache.org>.
For what's it worth, I agree with both of you. ;)
- A binary compatibility issue should not sink a release.
- If we want to clean up an API that would lead to an unavoidable binary compatibility issue, we should still do it and break binary compatibility.
- If there's an easy fix to retain binary compatibility, let's put these in.
As usual, just my $0.02.
-- Lars
________________________________
From: Jonathan Hsieh <jo...@cloudera.com>
To: Andrew Purtell <an...@gmail.com>
Cc: "dev@hbase.apache.org" <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>; Andrew Purtell <ap...@apache.org>
Sent: Tuesday, February 4, 2014 3:25 PM
Subject: Re: Binary API compatibility is not a requirement for any 0.98 release candidate
True. I think the difference here is that the KV stuff and comparator stuff
was marked that InterfaceAudience.Private for 0.96, and Scan was
InterfaceAudience.Public/InterfaceStability.Stable for 0.96.
The stronger markings mean we should really enforce the deprecation policy
in 0.98. .
Jon.
On Tue, Feb 4, 2014 at 3:18 PM, Andrew Purtell <an...@gmail.com>wrote:
> Jon,
>
> I find your "ship has sailed here" phrasing a bit odd because it was your
> changes to KV comparators that kicked off the original discussion on binary
> compatibility and, then, an agreement that binary API compat not be a
> criteria for 0.98 releases. Otherwise it would have been. :-)
>
> On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> Andrew,
>
> I basically agree with lars here -- the ship has sailed here. However,
> there are some patches that restored binary compat in places committed to
> 0.98 already. (IMO actually this would be an argument to fork earlier in
> the future)
>
> I have some comments on HBASE-10460. Specifically it is on a class that
> is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I think
> they fix there should get into 0.98.
>
> Jon.
>
>
>
> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
>
>> My $0.02...
>>
>> Wire (client-server and server-server) compatibility is a must have.
>> Binary compatibility should be a best effort. I.e. we shouldn't go out of
>> our way to break things, but if we want to clean up an API we should do
>> that.
>> So much for 0.98.
>>
>> Going forward...
>>
>> Once we go past version 1.0 and to semantic versioning this will need a
>> bigger discussion.
>>
>> As discussed in the past there are at least four angles here:
>> 1. Client-server wire compatibility
>> 2. Server-server wire compatibility
>> 3. Client binary compatibility
>> 4. Server interface binary compatibility (for coprocessors)
>>
>> #4 is surprisingly important as it basically turns into a #1 problem when
>> a project ships with coprocessors.
>>
>> Then we need to define compatibility rules for major/minor/patch versions.
>> In the last PMC meeting we had a start on this. We need to finish the
>> details.
>>
>> -- Lars
>>
>>
>> ----- Original Message -----
>> From: Andrew Purtell <ap...@apache.org>
>> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
>> Cc:
>> Sent: Monday, February 3, 2014 3:08 PM
>> Subject: Binary API compatibility is not a requirement for any 0.98
>> release candidate
>>
>> If you would like to change this consensus now, we can do so, and add it
>> as
>> a release criterion. That would require undoing the comparator cleanups
>> and
>> related breaking changes that went in as HBASE-9245 and subtasks. So let's
>> not. I am -1 on making a change like this late in the day, after we have
>> already had two RCs and I am hoping to get a third out tomorrow.
>>
>> --
>> 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
> // jon@cloudera.com // @jmhsieh
>
>
>
--
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Jonathan Hsieh <jo...@cloudera.com>.
True. I think the difference here is that the KV stuff and comparator stuff
was marked that InterfaceAudience.Private for 0.96, and Scan was
InterfaceAudience.Public/InterfaceStability.Stable for 0.96.
The stronger markings mean we should really enforce the deprecation policy
in 0.98. .
Jon.
On Tue, Feb 4, 2014 at 3:18 PM, Andrew Purtell <an...@gmail.com>wrote:
> Jon,
>
> I find your "ship has sailed here" phrasing a bit odd because it was your
> changes to KV comparators that kicked off the original discussion on binary
> compatibility and, then, an agreement that binary API compat not be a
> criteria for 0.98 releases. Otherwise it would have been. :-)
>
> On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> Andrew,
>
> I basically agree with lars here -- the ship has sailed here. However,
> there are some patches that restored binary compat in places committed to
> 0.98 already. (IMO actually this would be an argument to fork earlier in
> the future)
>
> I have some comments on HBASE-10460. Specifically it is on a class that
> is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I think
> they fix there should get into 0.98.
>
> Jon.
>
>
>
> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
>
>> My $0.02...
>>
>> Wire (client-server and server-server) compatibility is a must have.
>> Binary compatibility should be a best effort. I.e. we shouldn't go out of
>> our way to break things, but if we want to clean up an API we should do
>> that.
>> So much for 0.98.
>>
>> Going forward...
>>
>> Once we go past version 1.0 and to semantic versioning this will need a
>> bigger discussion.
>>
>> As discussed in the past there are at least four angles here:
>> 1. Client-server wire compatibility
>> 2. Server-server wire compatibility
>> 3. Client binary compatibility
>> 4. Server interface binary compatibility (for coprocessors)
>>
>> #4 is surprisingly important as it basically turns into a #1 problem when
>> a project ships with coprocessors.
>>
>> Then we need to define compatibility rules for major/minor/patch versions.
>> In the last PMC meeting we had a start on this. We need to finish the
>> details.
>>
>> -- Lars
>>
>>
>> ----- Original Message -----
>> From: Andrew Purtell <ap...@apache.org>
>> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
>> Cc:
>> Sent: Monday, February 3, 2014 3:08 PM
>> Subject: Binary API compatibility is not a requirement for any 0.98
>> release candidate
>>
>> If you would like to change this consensus now, we can do so, and add it
>> as
>> a release criterion. That would require undoing the comparator cleanups
>> and
>> related breaking changes that went in as HBASE-9245 and subtasks. So let's
>> not. I am -1 on making a change like this late in the day, after we have
>> already had two RCs and I am hoping to get a third out tomorrow.
>>
>> --
>> 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
> // jon@cloudera.com // @jmhsieh
>
>
>
--
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh
Re: Binary API compatibility is not a requirement for any 0.98 release candidate
Posted by Andrew Purtell <an...@gmail.com>.
Jon,
I find your "ship has sailed here" phrasing a bit odd because it was your changes to KV comparators that kicked off the original discussion on binary compatibility and, then, an agreement that binary API compat not be a criteria for 0.98 releases. Otherwise it would have been. :-)
> On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> Andrew,
>
> I basically agree with lars here -- the ship has sailed here. However, there are some patches that restored binary compat in places committed to 0.98 already. (IMO actually this would be an argument to fork earlier in the future)
>
> I have some comments on HBASE-10460. Specifically it is on a class that is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I think they fix there should get into 0.98.
>
> Jon.
>
>
>
>> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
>> My $0.02...
>>
>> Wire (client-server and server-server) compatibility is a must have.
>> Binary compatibility should be a best effort. I.e. we shouldn't go out of our way to break things, but if we want to clean up an API we should do that.
>> So much for 0.98.
>>
>> Going forward...
>>
>> Once we go past version 1.0 and to semantic versioning this will need a bigger discussion.
>>
>> As discussed in the past there are at least four angles here:
>> 1. Client-server wire compatibility
>> 2. Server-server wire compatibility
>> 3. Client binary compatibility
>> 4. Server interface binary compatibility (for coprocessors)
>>
>> #4 is surprisingly important as it basically turns into a #1 problem when a project ships with coprocessors.
>>
>> Then we need to define compatibility rules for major/minor/patch versions.
>> In the last PMC meeting we had a start on this. We need to finish the details.
>>
>> -- Lars
>>
>>
>> ----- Original Message -----
>> From: Andrew Purtell <ap...@apache.org>
>> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
>> Cc:
>> Sent: Monday, February 3, 2014 3:08 PM
>> Subject: Binary API compatibility is not a requirement for any 0.98 release candidate
>>
>> If you would like to change this consensus now, we can do so, and add it as
>> a release criterion. That would require undoing the comparator cleanups and
>> related breaking changes that went in as HBASE-9245 and subtasks. So let's
>> not. I am -1 on making a change like this late in the day, after we have
>> already had two RCs and I am hoping to get a third out tomorrow.
>>
>> --
>> 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
> // jon@cloudera.com // @jmhsieh
>
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Ted Yu <yu...@gmail.com>.
Patches for HBASE-10467 and HBASE-10460 have been checked in.
Cheers
On Tue, Feb 4, 2014 at 3:27 PM, Andrew Purtell <an...@gmail.com>wrote:
> I was going to roll a new RC now that the tag compression fix was in. No
> problem to wait for these if they are going in today.
>
>
> > On Feb 4, 2014, at 3:22 PM, Enis Söztutar <en...@gmail.com> wrote:
> >
> > We need a new RC anyway it seems. I say we fix HBASE-10460 and the HTD
> issues in the new RC and be at least do best effort thing. I guess we can
> get both of these committed today.
> >
> > Enis
> >
> >
> >> On Tue, Feb 4, 2014 at 3:17 PM, Ted Yu <yu...@gmail.com> wrote:
> >> The other issue Alex reported doesn't need to be fixed because
> >> HTableDescriptor is marked @InterfaceStability.Evolving, right ?
> >>
> >>
> >> On Tue, Feb 4, 2014 at 3:13 PM, Andrew Purtell <
> andrew.purtell@gmail.com>wrote:
> >>
> >> > I am not arguing the minor patches in question. Put them in. What I am
> >> > saying is voting -1 on a release because of binary compatibility
> issues
> >> > misses the earlier discussion where the consensus was not to do that.
> >> >
> >> > > On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com>
> wrote:
> >> > >
> >> > > Andrew,
> >> > >
> >> > > I basically agree with lars here -- the ship has sailed here.
> However,
> >> > there are some patches that restored binary compat in places
> committed to
> >> > 0.98 already. (IMO actually this would be an argument to fork
> earlier in
> >> > the future)
> >> > >
> >> > > I have some comments on HBASE-10460. Specifically it is on a class
> that
> >> > is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I
> think
> >> > they fix there should get into 0.98.
> >> > >
> >> > > Jon.
> >> > >
> >> > >
> >> > >
> >> > >> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org>
> wrote:
> >> > >> My $0.02...
> >> > >>
> >> > >> Wire (client-server and server-server) compatibility is a must
> have.
> >> > >> Binary compatibility should be a best effort. I.e. we shouldn't go
> out
> >> > of our way to break things, but if we want to clean up an API we
> should do
> >> > that.
> >> > >> So much for 0.98.
> >> > >>
> >> > >> Going forward...
> >> > >>
> >> > >> Once we go past version 1.0 and to semantic versioning this will
> need a
> >> > bigger discussion.
> >> > >>
> >> > >> As discussed in the past there are at least four angles here:
> >> > >> 1. Client-server wire compatibility
> >> > >> 2. Server-server wire compatibility
> >> > >> 3. Client binary compatibility
> >> > >> 4. Server interface binary compatibility (for coprocessors)
> >> > >>
> >> > >> #4 is surprisingly important as it basically turns into a #1
> problem
> >> > when a project ships with coprocessors.
> >> > >>
> >> > >> Then we need to define compatibility rules for major/minor/patch
> >> > versions.
> >> > >> In the last PMC meeting we had a start on this. We need to finish
> the
> >> > details.
> >> > >>
> >> > >> -- Lars
> >> > >>
> >> > >>
> >> > >> ----- Original Message -----
> >> > >> From: Andrew Purtell <ap...@apache.org>
> >> > >> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> >> > >> Cc:
> >> > >> Sent: Monday, February 3, 2014 3:08 PM
> >> > >> Subject: Binary API compatibility is not a requirement for any 0.98
> >> > release candidate
> >> > >>
> >> > >> If you would like to change this consensus now, we can do so, and
> add
> >> > it as
> >> > >> a release criterion. That would require undoing the comparator
> cleanups
> >> > and
> >> > >> related breaking changes that went in as HBASE-9245 and subtasks.
> So
> >> > let's
> >> > >> not. I am -1 on making a change like this late in the day, after
> we have
> >> > >> already had two RCs and I am hoping to get a third out tomorrow.
> >> > >>
> >> > >> --
> >> > >> 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
> >> > > // jon@cloudera.com // @jmhsieh
> >> > >
> >> >
> >
>
Re: Binary API compatibility is not a requirement for any 0.98 release candidate
Posted by Andrew Purtell <an...@gmail.com>.
I was going to roll a new RC now that the tag compression fix was in. No problem to wait for these if they are going in today.
> On Feb 4, 2014, at 3:22 PM, Enis Söztutar <en...@gmail.com> wrote:
>
> We need a new RC anyway it seems. I say we fix HBASE-10460 and the HTD issues in the new RC and be at least do best effort thing. I guess we can get both of these committed today.
>
> Enis
>
>
>> On Tue, Feb 4, 2014 at 3:17 PM, Ted Yu <yu...@gmail.com> wrote:
>> The other issue Alex reported doesn't need to be fixed because
>> HTableDescriptor is marked @InterfaceStability.Evolving, right ?
>>
>>
>> On Tue, Feb 4, 2014 at 3:13 PM, Andrew Purtell <an...@gmail.com>wrote:
>>
>> > I am not arguing the minor patches in question. Put them in. What I am
>> > saying is voting -1 on a release because of binary compatibility issues
>> > misses the earlier discussion where the consensus was not to do that.
>> >
>> > > On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>> > >
>> > > Andrew,
>> > >
>> > > I basically agree with lars here -- the ship has sailed here. However,
>> > there are some patches that restored binary compat in places committed to
>> > 0.98 already. (IMO actually this would be an argument to fork earlier in
>> > the future)
>> > >
>> > > I have some comments on HBASE-10460. Specifically it is on a class that
>> > is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I think
>> > they fix there should get into 0.98.
>> > >
>> > > Jon.
>> > >
>> > >
>> > >
>> > >> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
>> > >> My $0.02...
>> > >>
>> > >> Wire (client-server and server-server) compatibility is a must have.
>> > >> Binary compatibility should be a best effort. I.e. we shouldn't go out
>> > of our way to break things, but if we want to clean up an API we should do
>> > that.
>> > >> So much for 0.98.
>> > >>
>> > >> Going forward...
>> > >>
>> > >> Once we go past version 1.0 and to semantic versioning this will need a
>> > bigger discussion.
>> > >>
>> > >> As discussed in the past there are at least four angles here:
>> > >> 1. Client-server wire compatibility
>> > >> 2. Server-server wire compatibility
>> > >> 3. Client binary compatibility
>> > >> 4. Server interface binary compatibility (for coprocessors)
>> > >>
>> > >> #4 is surprisingly important as it basically turns into a #1 problem
>> > when a project ships with coprocessors.
>> > >>
>> > >> Then we need to define compatibility rules for major/minor/patch
>> > versions.
>> > >> In the last PMC meeting we had a start on this. We need to finish the
>> > details.
>> > >>
>> > >> -- Lars
>> > >>
>> > >>
>> > >> ----- Original Message -----
>> > >> From: Andrew Purtell <ap...@apache.org>
>> > >> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
>> > >> Cc:
>> > >> Sent: Monday, February 3, 2014 3:08 PM
>> > >> Subject: Binary API compatibility is not a requirement for any 0.98
>> > release candidate
>> > >>
>> > >> If you would like to change this consensus now, we can do so, and add
>> > it as
>> > >> a release criterion. That would require undoing the comparator cleanups
>> > and
>> > >> related breaking changes that went in as HBASE-9245 and subtasks. So
>> > let's
>> > >> not. I am -1 on making a change like this late in the day, after we have
>> > >> already had two RCs and I am hoping to get a third out tomorrow.
>> > >>
>> > >> --
>> > >> 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
>> > > // jon@cloudera.com // @jmhsieh
>> > >
>> >
>
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Enis Söztutar <en...@gmail.com>.
We need a new RC anyway it seems. I say we fix HBASE-10460 and the HTD
issues in the new RC and be at least do best effort thing. I guess we can
get both of these committed today.
Enis
On Tue, Feb 4, 2014 at 3:17 PM, Ted Yu <yu...@gmail.com> wrote:
> The other issue Alex reported doesn't need to be fixed because
> HTableDescriptor is marked @InterfaceStability.Evolving, right ?
>
>
> On Tue, Feb 4, 2014 at 3:13 PM, Andrew Purtell <andrew.purtell@gmail.com
> >wrote:
>
> > I am not arguing the minor patches in question. Put them in. What I am
> > saying is voting -1 on a release because of binary compatibility issues
> > misses the earlier discussion where the consensus was not to do that.
> >
> > > On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> > >
> > > Andrew,
> > >
> > > I basically agree with lars here -- the ship has sailed here. However,
> > there are some patches that restored binary compat in places committed to
> > 0.98 already. (IMO actually this would be an argument to fork earlier in
> > the future)
> > >
> > > I have some comments on HBASE-10460. Specifically it is on a class
> that
> > is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I
> think
> > they fix there should get into 0.98.
> > >
> > > Jon.
> > >
> > >
> > >
> > >> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org>
> wrote:
> > >> My $0.02...
> > >>
> > >> Wire (client-server and server-server) compatibility is a must have.
> > >> Binary compatibility should be a best effort. I.e. we shouldn't go out
> > of our way to break things, but if we want to clean up an API we should
> do
> > that.
> > >> So much for 0.98.
> > >>
> > >> Going forward...
> > >>
> > >> Once we go past version 1.0 and to semantic versioning this will need
> a
> > bigger discussion.
> > >>
> > >> As discussed in the past there are at least four angles here:
> > >> 1. Client-server wire compatibility
> > >> 2. Server-server wire compatibility
> > >> 3. Client binary compatibility
> > >> 4. Server interface binary compatibility (for coprocessors)
> > >>
> > >> #4 is surprisingly important as it basically turns into a #1 problem
> > when a project ships with coprocessors.
> > >>
> > >> Then we need to define compatibility rules for major/minor/patch
> > versions.
> > >> In the last PMC meeting we had a start on this. We need to finish the
> > details.
> > >>
> > >> -- Lars
> > >>
> > >>
> > >> ----- Original Message -----
> > >> From: Andrew Purtell <ap...@apache.org>
> > >> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> > >> Cc:
> > >> Sent: Monday, February 3, 2014 3:08 PM
> > >> Subject: Binary API compatibility is not a requirement for any 0.98
> > release candidate
> > >>
> > >> If you would like to change this consensus now, we can do so, and add
> > it as
> > >> a release criterion. That would require undoing the comparator
> cleanups
> > and
> > >> related breaking changes that went in as HBASE-9245 and subtasks. So
> > let's
> > >> not. I am -1 on making a change like this late in the day, after we
> have
> > >> already had two RCs and I am hoping to get a third out tomorrow.
> > >>
> > >> --
> > >> 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
> > > // jon@cloudera.com // @jmhsieh
> > >
> >
>
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Ted Yu <yu...@gmail.com>.
The other issue Alex reported doesn't need to be fixed because
HTableDescriptor is marked @InterfaceStability.Evolving, right ?
On Tue, Feb 4, 2014 at 3:13 PM, Andrew Purtell <an...@gmail.com>wrote:
> I am not arguing the minor patches in question. Put them in. What I am
> saying is voting -1 on a release because of binary compatibility issues
> misses the earlier discussion where the consensus was not to do that.
>
> > On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> >
> > Andrew,
> >
> > I basically agree with lars here -- the ship has sailed here. However,
> there are some patches that restored binary compat in places committed to
> 0.98 already. (IMO actually this would be an argument to fork earlier in
> the future)
> >
> > I have some comments on HBASE-10460. Specifically it is on a class that
> is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I think
> they fix there should get into 0.98.
> >
> > Jon.
> >
> >
> >
> >> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
> >> My $0.02...
> >>
> >> Wire (client-server and server-server) compatibility is a must have.
> >> Binary compatibility should be a best effort. I.e. we shouldn't go out
> of our way to break things, but if we want to clean up an API we should do
> that.
> >> So much for 0.98.
> >>
> >> Going forward...
> >>
> >> Once we go past version 1.0 and to semantic versioning this will need a
> bigger discussion.
> >>
> >> As discussed in the past there are at least four angles here:
> >> 1. Client-server wire compatibility
> >> 2. Server-server wire compatibility
> >> 3. Client binary compatibility
> >> 4. Server interface binary compatibility (for coprocessors)
> >>
> >> #4 is surprisingly important as it basically turns into a #1 problem
> when a project ships with coprocessors.
> >>
> >> Then we need to define compatibility rules for major/minor/patch
> versions.
> >> In the last PMC meeting we had a start on this. We need to finish the
> details.
> >>
> >> -- Lars
> >>
> >>
> >> ----- Original Message -----
> >> From: Andrew Purtell <ap...@apache.org>
> >> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> >> Cc:
> >> Sent: Monday, February 3, 2014 3:08 PM
> >> Subject: Binary API compatibility is not a requirement for any 0.98
> release candidate
> >>
> >> If you would like to change this consensus now, we can do so, and add
> it as
> >> a release criterion. That would require undoing the comparator cleanups
> and
> >> related breaking changes that went in as HBASE-9245 and subtasks. So
> let's
> >> not. I am -1 on making a change like this late in the day, after we have
> >> already had two RCs and I am hoping to get a third out tomorrow.
> >>
> >> --
> >> 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
> > // jon@cloudera.com // @jmhsieh
> >
>
Re: Binary API compatibility is not a requirement for any 0.98 release candidate
Posted by Andrew Purtell <an...@gmail.com>.
I am not arguing the minor patches in question. Put them in. What I am saying is voting -1 on a release because of binary compatibility issues misses the earlier discussion where the consensus was not to do that.
> On Feb 4, 2014, at 2:46 PM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> Andrew,
>
> I basically agree with lars here -- the ship has sailed here. However, there are some patches that restored binary compat in places committed to 0.98 already. (IMO actually this would be an argument to fork earlier in the future)
>
> I have some comments on HBASE-10460. Specifically it is on a class that is @InterfaceAudience.Public and @InterfaceStability.Stable -- and I think they fix there should get into 0.98.
>
> Jon.
>
>
>
>> On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
>> My $0.02...
>>
>> Wire (client-server and server-server) compatibility is a must have.
>> Binary compatibility should be a best effort. I.e. we shouldn't go out of our way to break things, but if we want to clean up an API we should do that.
>> So much for 0.98.
>>
>> Going forward...
>>
>> Once we go past version 1.0 and to semantic versioning this will need a bigger discussion.
>>
>> As discussed in the past there are at least four angles here:
>> 1. Client-server wire compatibility
>> 2. Server-server wire compatibility
>> 3. Client binary compatibility
>> 4. Server interface binary compatibility (for coprocessors)
>>
>> #4 is surprisingly important as it basically turns into a #1 problem when a project ships with coprocessors.
>>
>> Then we need to define compatibility rules for major/minor/patch versions.
>> In the last PMC meeting we had a start on this. We need to finish the details.
>>
>> -- Lars
>>
>>
>> ----- Original Message -----
>> From: Andrew Purtell <ap...@apache.org>
>> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
>> Cc:
>> Sent: Monday, February 3, 2014 3:08 PM
>> Subject: Binary API compatibility is not a requirement for any 0.98 release candidate
>>
>> If you would like to change this consensus now, we can do so, and add it as
>> a release criterion. That would require undoing the comparator cleanups and
>> related breaking changes that went in as HBASE-9245 and subtasks. So let's
>> not. I am -1 on making a change like this late in the day, after we have
>> already had two RCs and I am hoping to get a third out tomorrow.
>>
>> --
>> 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
> // jon@cloudera.com // @jmhsieh
>
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Jonathan Hsieh <jo...@cloudera.com>.
Andrew,
I basically agree with lars here -- the ship has sailed here. However,
there are some patches that restored binary compat in places committed to
0.98 already. (IMO actually this would be an argument to fork earlier in
the future)
I have some comments on HBASE-10460. Specifically it is on a class that is
@InterfaceAudience.Public and @InterfaceStability.Stable -- and I think
they fix there should get into 0.98.
Jon.
On Mon, Feb 3, 2014 at 9:46 PM, lars hofhansl <la...@apache.org> wrote:
> My $0.02...
>
> Wire (client-server and server-server) compatibility is a must have.
> Binary compatibility should be a best effort. I.e. we shouldn't go out of
> our way to break things, but if we want to clean up an API we should do
> that.
> So much for 0.98.
>
> Going forward...
>
> Once we go past version 1.0 and to semantic versioning this will need a
> bigger discussion.
>
> As discussed in the past there are at least four angles here:
> 1. Client-server wire compatibility
> 2. Server-server wire compatibility
> 3. Client binary compatibility
> 4. Server interface binary compatibility (for coprocessors)
>
> #4 is surprisingly important as it basically turns into a #1 problem when
> a project ships with coprocessors.
>
> Then we need to define compatibility rules for major/minor/patch versions.
> In the last PMC meeting we had a start on this. We need to finish the
> details.
>
> -- Lars
>
>
> ----- Original Message -----
> From: Andrew Purtell <ap...@apache.org>
> To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> Cc:
> Sent: Monday, February 3, 2014 3:08 PM
> Subject: Binary API compatibility is not a requirement for any 0.98
> release candidate
>
> If you would like to change this consensus now, we can do so, and add it as
> a release criterion. That would require undoing the comparator cleanups and
> related breaking changes that went in as HBASE-9245 and subtasks. So let's
> not. I am -1 on making a change like this late in the day, after we have
> already had two RCs and I am hoping to get a third out tomorrow.
>
> --
> 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
// jon@cloudera.com // @jmhsieh
Re: Binary API compatibility is not a requirement for any 0.98 release candidate
Posted by lars hofhansl <la...@apache.org>.
My $0.02...
Wire (client-server and server-server) compatibility is a must have.
Binary compatibility should be a best effort. I.e. we shouldn't go out of our way to break things, but if we want to clean up an API we should do that.
So much for 0.98.
Going forward...
Once we go past version 1.0 and to semantic versioning this will need a bigger discussion.
As discussed in the past there are at least four angles here:
1. Client-server wire compatibility
2. Server-server wire compatibility
3. Client binary compatibility
4. Server interface binary compatibility (for coprocessors)
#4 is surprisingly important as it basically turns into a #1 problem when a project ships with coprocessors.
Then we need to define compatibility rules for major/minor/patch versions.
In the last PMC meeting we had a start on this. We need to finish the details.
-- Lars
----- Original Message -----
From: Andrew Purtell <ap...@apache.org>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Cc:
Sent: Monday, February 3, 2014 3:08 PM
Subject: Binary API compatibility is not a requirement for any 0.98 release candidate
If you would like to change this consensus now, we can do so, and add it as
a release criterion. That would require undoing the comparator cleanups and
related breaking changes that went in as HBASE-9245 and subtasks. So let's
not. I am -1 on making a change like this late in the day, after we have
already had two RCs and I am hoping to get a third out tomorrow.
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Stack <st...@duboce.net>.
On Mon, Feb 3, 2014 at 8:49 PM, Stack <st...@duboce.net> wrote:
> ....
> I can write up a little section on binary compat story based off this
> thread. Will wait till we see what makes 0.98.
>
> We actually have a section on BC already in the refguide so would just
need to add section on 0.96->0.98.
St.Ack
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Stack <st...@duboce.net>.
On Mon, Feb 3, 2014 at 7:01 PM, Andrew Purtell <ap...@apache.org> wrote:
> I don't think we should shy away from breaking (binary API) changes until
> 1.0. Then the expectations of a stable API kick in, so fix what need fixing
> before. This was the rationale here. See the discussion around the time
> the KV changes went in on dev@ and the issues themselves. Minor changes
> like you point out are fine to commit to 0.98 branch ahead of the next RC
> but aren't blocking issues for release. This has been well discussed. It
> should not be surprising. We did not just "start the discussion". Changing
> the rules in the middle is not fair to the RM.
>
>
Thanks for putting the spotlight on BC Andrew and the reminder than once we
call it 1.0, we are stuck.
No harm minimizing pain we put on downstreamers so would be good putting
back the minor diffs.
I can write up a little section on binary compat story based off this
thread. Will wait till we see what makes 0.98.
St.Ack
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Andrew Purtell <ap...@apache.org>.
I don't think we should shy away from breaking (binary API) changes until
1.0. Then the expectations of a stable API kick in, so fix what need fixing
before. This was the rationale here. See the discussion around the time
the KV changes went in on dev@ and the issues themselves. Minor changes
like you point out are fine to commit to 0.98 branch ahead of the next RC
but aren't blocking issues for release. This has been well discussed. It
should not be surprising. We did not just "start the discussion". Changing
the rules in the middle is not fair to the RM.
On Monday, February 3, 2014, Enis Söztutar <en...@gmail.com> wrote:
> Thanks for starting the discussion.
>
> I think it should be ok to go w/o binary compat. The only downside is the
> extended effort the downstreamers have to bear, since they might have to
> release versions compiled against 96 or 98 separately.
>
> I went over the changes from Alex in client and hbase packages.
>
> It seems that the Scan change is the only one in the client package for
> binary compat for the Public interfaces. We have a patch at HBASE-10460.
>
> HBASE-10324 caused the changes in HTD to break the deprecated methods. But
> it is easy to fix.
>
> This leaves only the KV changes:
>
> http://people.apache.org/~jmhsieh/hbase_jdiff_report-p-0.96-c-0.98/changes.html
>
> KV is changed to private, so there is no point in trying to undo those
> changes I think.
>
> I would +1 documenting that 0.96 and 0.98 are not binary compatible, but in
> the mean time fix the 2 issues in Scan and HTD so that if the users are not
> using KV, they will be binary compat. What do you think?
>
> BTW, I've opened https://issues.apache.org/jira/browse/HBASE-10462 as a
> blocker against 1.0.
>
> Enis
>
>
> On Mon, Feb 3, 2014 at 3:12 PM, Nick Dimiduk <ndimiduk@gmail.com<javascript:;>>
> wrote:
>
> > FYI, our system tests recently discovered the class rename in HBASE-10431
> > also imposes a binary incompatibility for launching mapreduce jobs when
> > specifying 0.98's hbase-protocol.jar on the HADOOP_CLASSPATH.
> >
> >
> > On Mon, Feb 3, 2014 at 4:08 PM, Andrew Purtell <apurtell@apache.org<javascript:;>
> >
> > wrote:
> >
> > > If you would like to change this consensus now, we can do so, and add
> it
> > as
> > > a release criterion. That would require undoing the comparator cleanups
> > and
> > > related breaking changes that went in as HBASE-9245 and subtasks. So
> > let's
> > > not. I am -1 on making a change like this late in the day, after we
> have
> > > already had two RCs and I am hoping to get a third out tomorrow.
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Enis Söztutar <en...@gmail.com>.
Thanks for starting the discussion.
I think it should be ok to go w/o binary compat. The only downside is the
extended effort the downstreamers have to bear, since they might have to
release versions compiled against 96 or 98 separately.
I went over the changes from Alex in client and hbase packages.
It seems that the Scan change is the only one in the client package for
binary compat for the Public interfaces. We have a patch at HBASE-10460.
HBASE-10324 caused the changes in HTD to break the deprecated methods. But
it is easy to fix.
This leaves only the KV changes:
http://people.apache.org/~jmhsieh/hbase_jdiff_report-p-0.96-c-0.98/changes.html
KV is changed to private, so there is no point in trying to undo those
changes I think.
I would +1 documenting that 0.96 and 0.98 are not binary compatible, but in
the mean time fix the 2 issues in Scan and HTD so that if the users are not
using KV, they will be binary compat. What do you think?
BTW, I've opened https://issues.apache.org/jira/browse/HBASE-10462 as a
blocker against 1.0.
Enis
On Mon, Feb 3, 2014 at 3:12 PM, Nick Dimiduk <nd...@gmail.com> wrote:
> FYI, our system tests recently discovered the class rename in HBASE-10431
> also imposes a binary incompatibility for launching mapreduce jobs when
> specifying 0.98's hbase-protocol.jar on the HADOOP_CLASSPATH.
>
>
> On Mon, Feb 3, 2014 at 4:08 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > If you would like to change this consensus now, we can do so, and add it
> as
> > a release criterion. That would require undoing the comparator cleanups
> and
> > related breaking changes that went in as HBASE-9245 and subtasks. So
> let's
> > not. I am -1 on making a change like this late in the day, after we have
> > already had two RCs and I am hoping to get a third out tomorrow.
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Nick Dimiduk <nd...@gmail.com>.
FYI, our system tests recently discovered the class rename in HBASE-10431
also imposes a binary incompatibility for launching mapreduce jobs when
specifying 0.98's hbase-protocol.jar on the HADOOP_CLASSPATH.
On Mon, Feb 3, 2014 at 4:08 PM, Andrew Purtell <ap...@apache.org> wrote:
> If you would like to change this consensus now, we can do so, and add it as
> a release criterion. That would require undoing the comparator cleanups and
> related breaking changes that went in as HBASE-9245 and subtasks. So let's
> not. I am -1 on making a change like this late in the day, after we have
> already had two RCs and I am hoping to get a third out tomorrow.
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: Binary API compatibility is not a requirement for any 0.98
release candidate
Posted by Andrew Purtell <ap...@apache.org>.
And in case anyone might need clarification - _Wire_ compatibility IS a
requirement for a 0.98 release candidate.
On Mon, Feb 3, 2014 at 3:08 PM, Andrew Purtell <ap...@apache.org> wrote:
> If you would like to change this consensus now, we can do so, and add it
> as a release criterion. That would require undoing the comparator cleanups
> and related breaking changes that went in as HBASE-9245 and subtasks. So
> let's not. I am -1 on making a change like this late in the day, after we
> have already had two RCs and I am hoping to get a third out tomorrow.
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)