hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))
Date Wed, 22 Apr 2015 17:14:20 GMT
Just to clarify something, I've proposed edits that clarify the de-facto
practice, since additional methods are turning up in patch releases, but am
not taking a position.

So far we don't have consensus.

> + HBase uses Semantic Versioning for its release versioning with a caveat
that methods and members might be added in newer bug-fix releases that were
not present in the previous bug-fix release.

This is a good point. We should make this change too, to be consistent, or
if we don't want to make this change, then we should:
- Reject my proposal (I will make a new one clarifying with the opposite
meaning)
- Sink the current 1.0.1 RC
- Remove any changes in branch-1.0 that added new methods to the API
surface before proposing a new 1.0.1 RC


On Wed, Apr 22, 2015 at 10:03 AM, Josh Elser <josh.elser@gmail.com> wrote:

> While I can understand the desire to want to add things, I do think it
> makes things harder for users to reliably write code against versions of
> HBase which (by their view) should be completely compatible with one
> another.
>
> Take this extremely hypothetical situation: I'm new to HBase and start
> writing some code against HBase 1.0.1 which was just deployed at my $job. I
> don't _know_ what APIs are new, I just know what exists and treat that as
> acceptable for me to be using. Meanwhile in production, some other people
> find a bug with HBase 1.0.1 and roll back to 1.0.0 which they had been
> previously using. My reaction would be "of course my code should work with
> HBase 1.0.0, I only used the public API" when in fact this is not true.
>
> Personally, I think it's a little bold to say semver is even in use if
> this principal isn't being followed as it doesn't follow at all with my
> understanding on the guarantees defined by semver for bug-fix releases.
>
> That being said, if the intent *is* to allow ourselves to make these sorts
> of changes, I just think some sort of disclaimer should be present:
>
> - HBase uses Semantic Versioning for its release versioning
> + HBase uses Semantic Versioning for its release versioning with a caveat
> that methods and members might be added in newer bug-fix releases that were
> not present in the previous bug-fix release.
>
>
> Andrew Purtell wrote:
>
>> [Subject changed]
>>
>> On Tue, Apr 21, 2015 at 8:47 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>>
>>  I was a little surprised when I noticed method additions to
>>> InterfaceAudience.Public annotated classes. This means that a user could
>>> write code against 1.0.1 that would not work against 1.0.0 which seems
>>> undesirable for a bugfix release. I read over the book section on
>>> compatibility and didn't see this addressed, so I thought I'd ask.
>>>
>>
>>
>> Let's clarify this. It's not the first time this question has been asked.
>>
>> To get things moving:
>>
>> I propose the following addition to the "Client API compatibility" section
>> of Section 11.1:
>>
>> + APIs available in a patch version will be available in all later
>> + patch versions. However, new APIs may be added which will not be
>> + available in earlier patch versions.
>>
>> I propose the following change to the "Client Binary compatibility"
>> section
>> of Section 11.1:
>>
>> - Old client code can run unchanged (no recompilation needed) against new
>> jars.
>> + Client code written to APIs available in a given patch release
>> + can run unchanged (no recompilation needed) against the new
>> + jars of later patch versions.
>>
>>
>> What do you think?
>>
>> If these changes are (mostly) ok, then this clarifies in one direction.
>>
>> If these changes are not acceptable, I will propose edits that clarify
>> toward the opposite meaning. ‚Äč
>>
>>
>>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message