hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
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 16:32:18 GMT
I think these changes are Okay.

On Wed, Apr 22, 2015 at 9:29 AM, Andrew Purtell <apurtell@apache.org> 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