hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject 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:29:55 GMT
[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