(top-post since I can't find a better place to respond to everyone who
chimed in here)
Huge thanks, everyone! This was absolutely the best email thread (and
JIRA issue) I could've come back to after not keeping up with email for
the day.
Stack wrote:
On Tue, Aug 16, 2016 at 8:20 AM, Sean Busbey<bus...@apache.org> wrote:
On Tue, Aug 16, 2016 at 6:40 AM, Stack<st...@duboce.net> wrote:
On Tue, Aug 16, 2016 at 1:07 AM, Phil Yang<ud1...@gmail.com> wrote:
I notice that HBASE-15645 is made up of several commits and revert in
git,
maybe it is more convenient to apply a new patch to remove the added
methods.
Created a new issue (HBASE-16420
<https://issues.apache.org/jira/browse/HBASE-16420>) and waiting for
the
result of pre-commit build. The patch only fix the incompatibility of
1.1
and 1.2. Do we need keep the compatibility between 1.x branches? If so
we
need also remove new methods from branch-1.3 and branch-1. And seems
some
other issues also added new methods to non-Private interface on
branch-1/1.3...
Patch looks good Phil. Thanks for putting it up.
On your question, adding API in a manner that breaks compile is allowed
going by our updated understanding.
This should be "is not allowed" right?
Thanks Sean. Yes (Doc says right thing in HBASE-16422 patch)
My reading of the consensus in the thread thus far is that adding methods
to IA.Public interfaces won't be possible in the 1.y line of releases due
to breaking source compatibility,
HBASE-16422 makes exclusion for patch release only. It does not preclude
our breaking on minor versions.
1) starting to have a distinction between places we expect folks to just
consume API vs extend it?
I used to be in favor of this, but Andrew's concern on bikeshedding has me
reconsidering. Simpler rules seem better both to reduce the complexity of
communicating downstream and what the RMs have to keep in their heads when
evaluating changes.
This and the below would be better on another thread I'd say Sean.
Lets keep this thread for handling this little compat episode.
Thanks,
St.Ack
2) dropping our use of IS.Stable, IS.Evolving, etc.
I've never found this distinction particularly useful since we aren't very
consistent on it. The compat guide only specifies what it means for "server
side APIs" without really defining what that means precisely, and we use it
in client APIs as well. I think a reasonable reading of our current guide
could take the IS.Evolving designation to mean that the breaking change to
Table was okay, but reading the comments on PHOENIX-3116 that
interpretation would clearly be surprising to at least one set of
downstream folks. (Plus none of the discussions I saw around this change
used this rationale, so its presence or lack thereof wouldn't have changed
the conversation.)
