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 compatib
uot;dev@hbase.apache.org" ; lars hofhansl <
> la...@apache.org>; Andrew Purtell
> 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 diffe
___
> From: Jonathan Hsieh
> To: Andrew Purtell
> Cc: "dev@hbase.apache.org" ; lars hofhansl <
> la...@apache.org>; Andrew Purtell
> Sent: Tuesday, February 4, 2014 3:25 PM
> Subject: Re: Binary API compatibility is not a requirement for any 0.98
>
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 marki
gt;> > >> 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 coprocessor
gly 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.
>&
ility (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
> > versi
> 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 Messa
>> 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 -
> >
ibility 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
>> To: "dev@hbase.apache.org&qu
t;
> - Original Message -
> From: Andrew Purtell
> To: "dev@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 c
ssage -
From: Andrew Purtell
To: "dev@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. Tha
On Mon, Feb 3, 2014 at 8:49 PM, Stack 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
On Mon, Feb 3, 2014 at 7:01 PM, Andrew Purtell 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 change
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
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 packa
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 wrote:
> If you would like to change thi
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 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
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
19 matches
Mail list logo
