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 <[email protected]> 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<[email protected]> 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)
