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.el...@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.
